[zeromq-dev] Question about the PUBSUB design pattern when server restarts.

[Pieter Hintjens]

Bizarre. Endpoints don't get destroyed, they are just agreements on where to
meet. First step would be to see why publisher crashes (?) and then to see
why subscribers don't reconnect...  I'm kind of out of the action right now
but will try to reproduce the problem later this week.

-Pieter

-
On 15 Nov 2010 14:19, "Chuck Remes" <cremes.devlist at mac.com> wrote:
>
> On Nov 15, 2010, at 2:11 AM, Pieter Hintjens wrote:
>
>> Hi Janak,
>>
>>> Do I have to call connect from client side after every s_recv call ?
>>
>> No, you call once and 0MQ will reconnect to the publisher
>> automatically. You can try this with the wu example.
>>
>>> Currently, I see that if I dont call connect on SUB and PUB stops and 2
>>> minutes later starts again, memory usage on pub keeps on increasing ?
May
>>> be, its because it might be keeping it in queue for the sub to get the
data.
>>
>> I'm not sure about your description here. If pub stops, how can its
>> memory usage keep on increasing?
>>
>> If pub stops, sub will finish processing whatever data was in-flight,
>> and then stop. When pub starts again, it will send to all subs that
>> (re-)connect to it. They'll reconnect automatically as soon as they
>> find the pub socket is available again.
>
> I discussed this issue with Janak on IRC. When he says that the publisher
"stops" he means that the process goes down. Two minutes later he restarts
it but the subscribers do not see any further messages.
>
> In this case the publisher is BINDing to the endpoint while the
subscribers are all CONNECTing. I suggested putting a FORWARDER device in
between so that publishers and subscribers could come and go without
destroying the endpoints which is what was happening in his original
scenario.
>
> cr
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20101115/09fd1b08/attachment.htm>