Race condition when using ZMQ_IDENTITY
Description
Environment
Compiled/Run on:
Linux Bonobo-Extreme 3.8.0-26-generic #38-Ubuntu SMP Mon Jun 17 21:43:33 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
8 cores - Intel(R) Core(TM) i7-3630QM CPU @ 2.40GHz
gcc version: 4.7.3
Activity
Show:
starcheng September 25, 2013 at 6:54 AMEdited
It may be same as LIBZMQ-556.
Because, ctx_t::create_socket runs in a thread while ctx_t::destroy_socket in reap thread.
If close a dealer socket with identity named as 'A' and create a new socket with the same identity with no sleep at client, the following sequence may happen at server: new client attached -> old client dettached. In this scenario, router would not attach new pipe.
There appears to be a race condition with opening/closing/re-opening a ZMQ_REQ socket that has it's identity explicitly set via zmq_setsockopt using ZMQ_IDENTITY. If the socket is immediately re-opened, any message sent on the new ZMQ_REQ socket isn't received by the ZMQ_REP socket. This also occurs if the ZMQ_REP socket is replaced with a ZMQ_ROUTER socket (This is where the problem was initially noticed).
The race condition doesn't occur if there's a 1 second sleep added between closing the socket and re-opening it.
The test program below demonstrates the problem.
It does the following:
. The thread '_Server' is created in main() and performs the following:
Create a ZMQ_REP socket.
Bind to 'inproc:://server'.
In a loop, poll for input on the ZMQ_REP socket and send/echo all
messages received back through the socket.
. main() performs the following in a loop:
Create a ZMQ_REQ socket.
Set the socket identity to 'test_id'
Connect to 'inproc:://server'.
Send 'test message'
Receive and print the message that was sent back.
Close the socket.