[zeromq-dev] ZMQ 2.2.1 / JNI / High water mark does have no effect

Michel Pelletier pelletier.michel at gmail.com
Fri May 2 18:51:13 CEST 2014


Even if there was a way to get the "fullness" of a queue, the answer
wouldn't be very meaningful.  Messages can be queued up "in-flight" in
kernel and other network device buffers.  This is also why setting HWM to 1
on each side often confuses people when they see many more messages being
sent until send blocks.

-Michel


On Fri, May 2, 2014 at 6:28 AM, Andreas Finke <Andreas.Finke at solvians.com>wrote:

>  Hi Murf,
>
>  in that version there is no chance to see it. You only can be aware of
> it, if the socket enters an exceptional state. I do not know yet about
> higher versions. I will post it here when I know.
>
>  @Michel: Thanks a lot for your investigation. I think we need to switch
> to the most recent version then.
>
>  Andreas
>  ------------------------------
> *From:* zeromq-dev-bounces at lists.zeromq.org [
> zeromq-dev-bounces at lists.zeromq.org] on behalf of Steve Murphy [
> murf at parsetree.com]
> *Sent:* Friday, May 02, 2014 6:05 AM
> *To:* ZeroMQ development list
> *Subject:* Re: [zeromq-dev] ZMQ 2.2.1 / JNI / High water mark does have
> no effect
>
>   I have a question--
>
>  wrt the high water mark, I looked thru the
>  libzmq code, to see if there was any way to
>  monitor the "fullness" of the buffer...
>  and didn't find anything. Am I missing
>  anything? It might be nice to see how many
>  items are buffered, how many have been tossed,
>  stuff like that...?
>
>  murf
>
>
> On Thu, May 1, 2014 at 2:42 PM, Michel Pelletier <
> pelletier.michel at gmail.com> wrote:
>
>> Your using a pretty old version of zeromq.  This is likely a problem that
>> has been fixed in future versions.  I rewrote your example in Python with
>> the latest pzmq and zeromq 4.1.0, and send blocked unless I passed
>> zmq.NOBLOCK, as expected.
>>
>>  https://gist.github.com/michelp/bc20aadc554c6331608f
>>
>>  -Michel
>>
>>
>>
>>  On Wed, Apr 30, 2014 at 11:54 AM, Andreas Finke <
>> Andreas.Finke at solvians.com> wrote:
>>
>>>   Hi all,
>>>
>>>  I have a question about a socket's high water mark setting. In our
>>> Java applications this setting does somehow not apply and we are ending up
>>> in using up native memory resulting in a crash of the application. I
>>> created a small example to show the problem.
>>>
>>>  http://pastebin.com/bkwbqUv7
>>>
>>>  1. A pull socket is created and bound to port 10000 (line 2)
>>> 2. The pulls socket does never receive any message
>>> 2. A push socket is created connecting to the pull socket (line 12)
>>> 3. A high water mark of 1 is set to both sockets (line 4 + 13)
>>> 5. Success of each sending try is printed to std out (line 21)
>>>
>>>  Both sockets are started as separate programs. In this scenario I
>>> would expect that the push client is able to deliver 2 messages due to the
>>> high water mark setting (1 + 1 ). I am ending up with:
>>>
>>>  Try 85742: true
>>> Try 85743: false
>>>
>>>  This means about 80 T messages are queued before the push socket
>>> starts blocking.
>>>
>>>  Regarding the api doc http://api.zeromq.org/2-2:zmq-socket the
>>> behaviour of ZMQ_PUSH in case of an exceptional state (like high water mark
>>> is reached) should be "BLOCKING".
>>>
>>>  Does anyone has an idea what I maybe get wrong about this?
>>>
>>>  Thanks a lot in advance.
>>>
>>>  Andreas
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>  _______________________________________________
>>> 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
>>
>>
>
>
> --
>
> Steve Murphy
> ParseTree Corporation
> 57 Lane 17
> Cody, WY 82414
> ✉  murf at parsetree dot com
> ☎ 307-899-5535
>
>
>
> _______________________________________________
> 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/20140502/d591f2da/attachment.htm>


More information about the zeromq-dev mailing list