[zeromq-dev] odd zmqstream.py behavior

[MinRK]

Interesting, if weird:

With current pyzmq trunk and zeromq 2.0.9, your script behaves exactly as it
should on my laptop (system Python 2.6.1, OSX 10.6.4), but hangs on Linux
(Ubuntu 10.04 x86_64, system Python 2.6.5). As far as I know, everything
else is the same version for both; certainly zmq and pyzmq.

Any ideas?

I changed the zmqstream behavior such that it still calls socket.close(),
but as a DelayedCallback.  This is now the only difference between the
zmqstream.close() behavior and the tornado iostream.close() behavior.  This
way, even if socket.close() blocks and mucks tornado up, at least the
*first* error will be reported and logged. However, I find that
socket.close() does not block when I do this, though that is likely just due
to the fact that the send has completed by the time the close callback
fires.

-MinRK

On Wed, Oct 6, 2010 at 14:27, Steve Huffman <steve at hipmunk.com> wrote:

> I can't actually reproduce the issue at the head of this topic with master,
>> though.  I see the loop properly logging the error and marching right along,
>> having closed and detached the socket. Can you post a sample of where it
>> hangs, and check against my zmqstream branch on github (
>> http://github.com/minrk/pyzmq/tree/zmqstream) to see if that behaves any
>> better?
>>
>
> Attached is a script that demonstrates the error. I run ./zmqtest.py
> "server" to start a listener, and ./zmqtest.py to send a test message. There
> is an error in the on_send callback for the client, which causes the
> hanging.
>
> It works on your branch, but that isn't a huge surprise because the close()
> that causes the hanging is commented out. Uncommenting that close() causes
> it to hang as does on the current master.
>
> I haven't been able to reproduce this error using vanilla pyzmq without
> ioloop/zmqstream, but my zmq experience is limited.
>
> Steve
>
>
>
>
>
>> I'm using zmq 2.0.9.
>>
>> -MinRK
>>
>> On Mon, Oct 4, 2010 at 20:20, Brian Granger <ellisonbg at gmail.com> wrote:
>>
>>> Hi,
>>>
>>> Min and I looked at this today and this is a bug in pyzmq.  When a
>>> callback in the eventloop raises, we are currently closing the socket,
>>> which we should not do.  We are still figuring out the error handling
>>> symantics, but we should have a fix in place soon in pyzmq master.
>>>
>>> Cheers,
>>>
>>> Brian
>>>
>>> On Fri, Oct 1, 2010 at 7:08 PM, Pieter Hintjens <ph at imatix.com> wrote:
>>> > On Sat, Oct 2, 2010 at 3:58 AM, Steve Huffman <steve at hipmunk.com>
>>> wrote:
>>> >
>>> >> I don't think so. I'll try the new version, but what the behavior I'm
>>> seeing
>>> >> is zmq_close() doesn't return when an exception is thrown in the
>>> callback.
>>> >
>>> > I didn't read your email properly, sorry... zmq_close() should not
>>> block.
>>> >
>>> > If you can follow what zmqstream is doing, and get a straight pyzmq
>>> > example that has the same behavior, that'll make it easier to debug.
>>> >
>>> > -Pieter
>>> > _______________________________________________
>>> > zeromq-dev mailing list
>>> > zeromq-dev at lists.zeromq.org
>>> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>> >
>>>
>>>
>>>
>>> --
>>> Brian E. Granger, Ph.D.
>>> Assistant Professor of Physics
>>> Cal Poly State University, San Luis Obispo
>>> bgranger at calpoly.edu
>>> ellisonbg at gmail.com
>>> _______________________________________________
>>> zeromq-dev mailing list
>>> zeromq-dev at lists.zeromq.org
>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>>
>>
>>
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>
>>
>
> _______________________________________________
> 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/20101006/98169097/attachment.htm>