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

Steve Murphy murf at parsetree.com
Fri May 2 06:05:26 CEST 2014


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20140501/3365126f/attachment.htm>


More information about the zeromq-dev mailing list