When one subscriber socket is closed, another subscriber socket fails to function properly
Description
Environment
Linux
Attachments
Activity
Martin Hurton April 2, 2012 at 7:57 PM
Commit 4c93fc25879213824c4fb4c9545f895ed7f43b95 seems to fix this. Can we close/resolve this issue?
DouglasY March 25, 2012 at 5:20 PM
pull request for fix: https://github.com/zeromq/libzmq/pull/291
DouglasY March 24, 2012 at 4:58 PM
This still occurs on the latest version in git
What appears to happen is the first part of the second multi-part message is dropped and never sent (as seen by strace). sending more messages works successfully. The order to the socket opening and closing appears to matter. The first socket continues to work as expected after closing the second socket, but not vice-versa. The affected socket always appears to be the last one to be opened which is connected to the pub socket (not necessarily the last one to connect to the socket). the tcp transport is equally affected as the ipc.
Calvin de Vries February 17, 2012 at 4:18 PMEdited
I'm fairly certain that I'm seeing this bug in production (I'm using 3.0.2 as well). I have no issues with upgrading to 3.1, especially since Pieter is talking about do a stable release. Before that, though, I think we need to be certain that this isn't happening in 3.1.
I have attached a python program that demonstrates this bug. Basically, at one point in the program, both subscribers are receiving messages just fine (the sleep allows the socket time to setup, on my system). After closing subscriber1 socket, we publish another message and subscriber2 cannot receive it, it just hangs. This is not a late subscriber problem because we do receive a message earlier in the program.
Also, I ran this test script on 2.1.11 and it works fine.