[zeromq-dev] mailbox.cpp Assertion

[Michel Pelletier]

>From the trace it looks like the call to write(2, ...) to stderr is
failing with EBADF (a curiosity in itself), the original assertion is
because cpipe.read() in zmq::mailbox_t::recv returned false when the
mailbox was not active.  I know you mentioned you don't have an
isolated case, but finding out why the mailbox pipline read is failing
is the key to this.

If it's the case where there hasn't been a command in a while, and you
reconnect it's a SUB socket, so it seems like setting a LINGER would
have no effect.  I think Chuck might have the right idea on
rescheduling the reconnection to some point in the future.  Do you
have the complete trace including the Python C stack?

-Michel

On Mon, Jul 9, 2012 at 12: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?
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>