nng_close occasionally hang on Windows

[appleprince]

Note that by filing an issue, you agree that you have read and agreed to
our contribution guidelines.

NNG & Platform details.

NNG 1.2.6 & 1.3.0
Windows 10

Expected Behavior

nng_close returns with socket closed

Actual Behavior

nng_close occasionally hanged and not returned

Steps to Reproduce

1. create a push0 & a pull0 node with localhost tcp connection.
2. producer produces messages with heavy loading. (about 300k messages with 2M bytes payload in 30 seconds)
3. invoke nng_close to shut down connection immediately and nng_close occasionally hanged.

NNG 1.1.1, 1.2.6 & 1.3.0 have been tested. Both NNG 1.2.6 & 1.3.0 occasionally hanged on nng_close, but NNG 1.1.1 does not hang.

[appleprince]

I did more tests to investigate this issue. If I add a brief waiting (thread sleep) before invoking nng_close, everything works smoothly. So my guess is that the unfinished transmission is interfering with the nng_close operation.

[gdamore]

Thanks for the information. I will investigate.

[gdamore]

Which side did you invoke close on?

[appleprince]

Close is invoked on the pull0 side.

[appleprince]

The send buffer size option of push0 node (NNG_OPT_SENDBUF) and the receive buffer size option of pull0 node (NNG_OPT_RECVBUF) are both set to 8192 in the previous tests. I removed both options from my test code today and the hang does not occurs. Did I do something wrong with these two options?

[gdamore]

This is helpful information. Thanks.

[gdamore]

Out of curiosity, how many CPU cores are present on your system?

[appleprince]

Intel i7-6700 (4 cores). 4GB of RAM (available RAM less than 1GB actually)

[enricoschroeder]

Hi everybody! I encountered a similar issue. Not sure if it is related because the setup is different, but the symptom (nng_close() hangs) is the same.

Here is my setup:

• nng 1.3.0 on Windows (6-core Intel i7-8750H)
• launching two processes that immediately create a raw bus socket each and try to nng_listen() to the same tcp address
• one of the nng_listen() calls fails with NNG_EADDRINUSE (this is expected since only one of the nng_listen() calls should succeed)
• calling nng_close() on the socket for which the listen call failed

Expected behavior:
nng_close() should close the socket and return
Experienced behavior:
nng_close() hangs and does not return

[gdamore]

Thanks for the information. This is helpful feedback, and may help me isolate the problem.

[gdamore]

I think its possible that there were two separate issues. I've found a bug in the TCP transport which affects all platforms, and I think there was a bug in the abort handling as well.

[gdamore]

I'm going to push the fixes I have so far. I am about 99% certain that this will fix your bug. Stay tuned.

[enricoschroeder]

Unfortunatly, I cannot confirm that the bug is fixed. The problem still occurs. However, as described above I encounter it when using (raw) bus sockets, which differs from all the other issues. Should I create a separate issue for this?