Open gbonnefille opened 9 years ago
I added a test to demonstrate the issue.
Thanks for the reporting. It could be a known issue as zmq.connect
is an asynchronous operation. zmq.send
will return false
with EAGAIN
on the second client. That would be a workaround to detect the buggy situation.
@gbonnefille Are you still experiencing this issue using the latest version of JeroMQ?
https://github.com/zeromq/jeromq/blob/master/src/test/java/zmq/socket/pair/TestPairTcp.java#L46
There is a test for this issue. Unsure of what the expected behaviour is.
IMHO, the matter is that the second client is able to connect to a pair while the pair is already connected. I would expect something to detect this second client will never receive any data.
Any idea to detect this situation (on the client side)?
I agree with @gbonnefille. It seems like the expected behavior is that JeroMQ should not let you connect a client to a PAIR socket if there is already something else connected.
I just ran across this in the zguide:
This is the first time we've shown an example using PAIR sockets. Why use PAIR? Other socket combinations might seem to work, but they all have side effects that could interfere with signaling:
You can use PUSH for the sender and PULL for the receiver. This looks simple and will work, but remember that PUSH will distribute messages to all available receivers. If you by accident start two receivers (e.g., you already have one running and you start a second), you'll "lose" half of your signals. PAIR has the advantage of refusing more than one connection; the pair is exclusive.
I'm not really sure how we would pull that off, technically. It sounds like maybe libzmq does it somehow? I haven't tested it, but from the zguide, it sounds like that's the design.
I tried to enforce the expected behaviour by setting the backlog to 1, but nothing changed.
sb.setSocketOpt(zmq.ZMQ.ZMQ_BACKLOG, 1);
When setting a PAIR socket over TCP, I'm able to create 2 clients connecting to a single bound/passive endpoint. Following the PAIR description, I would expect that no more client are accepted since the communication is established between two parts.
From the point of view of the second client, the connection is established. Nevertheless, the messages from the second client seems to not be received by the bound/passive endpoint.
It would be better to not accept more client since connection is established. Current behaviour is quite buggy as client seems to be connected but unable to communicate.