[zeromq-dev] High Water Mark Bug in 3.1.0 (was Re: Potential Bug Exposed w/ Haskell Driver)

[Michael Craig]

A helpful denizen of IRC pointed me to the ZeroMQ Jira, where I filed an
issue:

https://zeromq.jira.com/browse/LIBZMQ-317

Mike Craig



On Mon, Jan 23, 2012 at 4:11 PM, Michael Craig <mkscrg at gmail.com> wrote:

> Toralf determined that this bug relates to the receive high water mark,
> and it seems to be a problem with the native library. If ZMQ_RCVHWM is set
> to 1000 (the default), then the last message of a 1001-message batch is
> lost. Both of us have posted test cases (in C++ and C) on the GitHub issue
> page for zeromq-haskell:
> https://github.com/twittner/zeromq-haskell/issues/13
>
> Mike Craig
>
>
>
> On Mon, Jan 23, 2012 at 12:49 PM, Michael Craig <mkscrg at gmail.com> wrote:
>
>> Updates on the GitHub issue page. Bug seems to be specific to the 1001st
>> message sent and common across transports and socket types. I'm pretty sure
>> it's a problem with the library, not a core library issue.
>>
>> Mike Craig
>>
>>
>>
>>
>> On Mon, Jan 23, 2012 at 12:01 PM, Michael Craig <mkscrg at gmail.com> wrote:
>>
>>> Oops, pasted the same link twice. I just added this as an issue on the
>>> github page for the library, so you can see the code there:
>>>
>>> https://github.com/twittner/zeromq-haskell/issues/13
>>>
>>> Mike Craig
>>>
>>>
>>>
>>>
>>> On Mon, Jan 23, 2012 at 11:46 AM, Michael Craig <mkscrg at gmail.com>wrote:
>>>
>>>> I'm using the Haskell binding to ZeroMQ 3.x (found here:
>>>> http://hackage.haskell.org/package/zeromq3-haskell-0.1.2) on ghc
>>>>  7.2.1 on Max OS X 10.7.
>>>>
>>>> I was trying to write a throughput test for Pair sockets and came
>>>> across a bug (I think). Here's the code:
>>>> http://hackage.haskell.org/package/zeromq3-haskell-0.1.2
>>>>
>>>> `pusher n` sends a message saying "n", followed by n more messages,
>>>> each of which says "i" w/ 1 <= i <= n.
>>>> `puller` reads "n" from the first message and then receives n more
>>>> messages, printing each as it gets them and timing the whole process. (The
>>>> printing behavior was put in after the bug was found.)
>>>>
>>>> Start two separate ghci sessions and call one of the above in each. On
>>>> my machine, `pusher 1` up through `pusher 999` run as expected, but `pusher
>>>> 1000` or any higher hangs while receiving the 1000th message.
>>>>
>>>> Thoughts?
>>>>
>>>> Cheers,
>>>> Mike Craig
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20120123/7f0e68d6/attachment.htm>