Race condition when using ZMQ_IDENTITY

Description

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.

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 AM
Edited

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.

Details

Assignee

Reporter

Components

Affects versions

Priority

Created July 24, 2013 at 6:48 PM
Updated September 25, 2013 at 6:58 AM