[zeromq-dev] [PATCH] Publisher side filtering

Gerard Toonstra gtoonstra at gmail.com
Mon Jan 31 13:47:32 CET 2011

Hi Martin,

I recompiled and tested things here. I'm using a single pub with multiple
subs and one broker. The broker is a
custom app to relay messages with a bit of custom topic filtering for
pub->sub traffic, all using standard xsub and xpub sockets.

When used with some care, the subscription process works fine. The broker
runs and the subs subscribe as normal.
I do notice that when brokers or subs are restarted quickly in succession,
at some point the subscriptions remain
"stuck" somewhere, most likely in the "read" part of the PUB socket.

So what I see happen once in a while:

- SUB is started
- broker is started
- PUB is started
- things work ok
- restart SUB couple of times after it sent the sub request to the broker
- no messages yet appear in the publisher (the printf debug statement you
put there about receiving unsub/sub requests).
- restart broker
- 1 second later, the PUB displays "couple of times" sub requests + 1.

Because there are as many messages as restarts and both the broker and subs
were restarted, this looks like the PUB is
piling up messages for some reason. I noticed that the "pub_t::xsend" method
doesn't call "has_in" prior to executing
the recv in the while loop and was wondering whether something may be
failing over there?

When this occurs at some point, it's usually after a broker restart. The
messages from the sub fail to get to the pub.
When the broker is restarted again, they all show up together in one go. I
think this is related to the "has_in" method
probably?   (as if there's an invalid pipe ahead of the new valid pipe that
didn't get removed, or something like that).



On Fri, Jan 28, 2011 at 12:59 PM, Martin Sustrik <sustrik at 250bpm.com> wrote:

> Hi Gerard,
>  This is patched against "sub-forward" branch.
>> With this fix, the subscriptions are always forwarded upstream,
>> regardless of which process is terminated.
> I fixed the patch to handle some corner cases.
> Also, the subscription pipe is dropped and re-instantiated on the PUB side.
> This will allow XPUB socket to drop the corresponding subscriptions from its
> map/trie when subscriber shuts down.
> The changes are applied to sub-forward branch.
> Let me know whether it works as expected.
> Martin

Gerard Toonstra
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20110131/627c9a9f/attachment.htm>

More information about the zeromq-dev mailing list