[zeromq-dev] Possible bug in ZMQ3.1 with REP/REQ socket polling

[MinRK]

On Sat, Nov 12, 2011 at 13:16, Richard Smith <rsmith at rsbatechnology.co.uk>wrote:

> Hi,
>
> I am the maintainer of the Haxe 0MQ binding (
> http://github.com/rjsmith/hxzmq) and I am currently adding experimental
> 0MQ 3.1 support ( I am going to skip 3.0).  All but one of my 49 unit tests
> are now passing. But  I have found an issue with the 0MQ 3.1 zmq_poll
> method call indicating the readiness of a brand new REP socket to be read
> from (by setting the revents array flag for the REP socket), even though no
> messages have been sent to it from the similarly brand-new REQ socket to
> which it is connected.  In 0MQ 2.1.10, the same code doesn't exhibit this
> behaviour (ie the zmq_poll call does not indicate any non-blocking read /
> write state for the REP socket, which is what I would expect).
>
> I have also found that:
> 1. The behaviour is only for ipc and tcp (I havent tested with pgm).
>  inproc is OK (REP socket not flagged as readable)
> 2. This only seems to an issue for REP sockets.  Other tests I have done
> for PUB/SUB and PAIR/PAIR connections do not show this behaviour in ZMQ 3.1
> 3. I have also noticed that a zmq_poll done immediately after sending a
> message on the REQ socket shows that the REQ socket has something waiting
> to be read.
>

> I have added a Haxe code snippet here that shows the series of 0MQ calls
> using the hxzmq binding library
>
> http://gist.github.com/1361080
>
> I am not that familiar with native C compilation (I cheat and use the
> hxcpp haxe compiler for building all my 0MQ haxe code!) so havent yet tried
> to reproduce with a C language example.
>
> I thought I'd raise this to the group in case I have found a hitherto
> unknown 3.1 "feature".  Or I missed it in the documentation / mailing
> lists!  Happy to help track this down ....
>


I am pretty sure this is a bug, and a very serious one - if POLLIN is set,
there should be a message waiting for recv, but there isn't one.  Further,
you can actually make messages arrive (on ROUTERs) that shouldn't by adding
extra connections.  I reported this earlier in the week as part of
LIBZMQ-280 <https://zeromq.jira.com/browse/LIBZMQ-280> on Jira.  It affects
ROUTER/DEALER as well as REP.

-MinRK

>

>
> Regards,
>
> Richard
>
>
> _______________________________________________
> 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/20111112/88e3132b/attachment.htm>