[zeromq-dev] Duplicate messages on subscriber reconnect in pub/sub pair
benn at f5.com
Fri May 13 01:21:40 CEST 2011
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: zeromq-dev-bounces at lists.zeromq.org [mailto:zeromq-dev-bounces at lists.zeromq.org] On Behalf Of Benn Bollay
Sent: Thursday, May 12, 2011 3:36 PM
To: zeromq-dev at lists.zeromq.org
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.
* Is this expected?
* What should I be doing differently to prevent this from happening?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the zeromq-dev