[zeromq-dev] Duplicate messages on subscriber reconnect in pub/sub pair

[Benn Bollay]

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.

My questions:

*         Is this expected?

*         What should I be doing differently to prevent this from happening?

Cheers,
--B
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20110512/841e44c1/attachment.htm>