There are two details I'd like to add to this. First, the approach I used to close the fd - gdb and calling close(fd) explicitly - hits an unexpected behavior with the epoll mechanism. On fd close, epoll automatically - and, as best I can determine, silently - removes the fd from the event set. That means no notifications occur.
However, I would not be surprised if the internal tracking in 0mq simply tracks this by fd. Since the client reconnects so rapidly, it gets the same fd with the server, and a duplicate entry is contained within the internal tracking objects. This, I suspect, explains the duplicate messages. I'd like some independent clarification of this analysis. From: [email protected] [mailto:[email protected]] On Behalf Of Benn Bollay Sent: Thursday, May 12, 2011 3:36 PM To: [email protected] Subject: [zeromq-dev] Duplicate messages on subscriber reconnect in pub/sub pair Hi all - Using bog standard code (see http://pastebin.com/W3AvhQn5), and then forcing the tcp connection between the publisher and the subscriber to be reset, I am seeing duplicate messages on the subscriber's side. I've observed this behavior both in 2.0 and in 2.1.7, and in C and python code. Basic timeline of events: * Start up publisher on some regular message generation loop * Start up subscriber connecting to publisher. * Validate that subscriber sees one message per publisher message. * Force the connection to be closed - in my case, I attached gdb to the python process and close(fd)'ed the non-listening socket (easily identifiable via lsof). * The subscriber auto-reconnects, but now receives duplicates of every message being sent. My questions: * Is this expected? * What should I be doing differently to prevent this from happening? Cheers, --B
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
