[zeromq-dev] mailbox.cpp Assertion

[Thomas S Hatch]

On Mon, Jul 9, 2012 at 1:59 PM, Thomas S Hatch <thatch45 at gmail.com> wrote:

>
>
> On Mon, Jul 9, 2012 at 1:43 PM, Chuck Remes <lists at chuckremes.com> wrote:
>
>> On Jul 9, 2012, at 2:17 PM, Thomas S Hatch wrote:
>>
>> Yes, they are, here is the code:
>> https://github.com/saltstack/salt/blob/develop/salt/minion.py#L470
>>
>> I do not doubt that I have made a mistake in here
>>
>>
>> I see that you are unregistering, closing the socket, and then
>> immediately creating a new socket with the same IDENTITY.
>>
>> I did not see any code setting the LINGER option to drop packets, so if a
>> late packet arrives I suppose it could cause that zmq_close() to hang.
>>
>> Alternately, reusing the IDENTITY before the socket is completely closed
>> (an async operation) may be a cause. Any chance you can close the socket
>> and then schedule (within your loop) the creation of a replacement socket a
>> few milliseconds later?
>>
>> These are just two guesses based on 5m review of the code. I hope it
>> sparks an idea or a new avenue to pursue.
>>
>> cr
>>
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>
>> Thanks!
> Is there a way to check if the socket is completely closed? will
> socket.closed accurately return this data?
>
Actually, I should ask...

The main issue we are seeing in here is that the SUB socket looses
connection from the PUB socket when connecting over unreliable connections
like the internet. Is there a way to detect if the SUB socket is still
connected to the PUB socket?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20120709/78dd3bfb/attachment.htm>