[zeromq-dev] Potential Memory Leak in JZMQ 2.x.x running on top of ZeroMQ 3.2.3 for Multicast Publishing?

[Steven McCoy]

On 18 June 2013 18:23, Chinmay Nerurkar <chinmay.nerurkar at fusionts.com>wrote:

> What effect do the options ZMQ_RECOVERY_IVL and ZMQ_RATE have on the ZMQ
> SUB
> socket while connected to PGM?
>

There is a transmit window for PUB and a receive window for SUB.

The two parameters define the size of the window, in addition ZMQ_RATE
defines the rate limiter.

The transmit window should be equal to or larger than the receive window.


> I have a ZMQ PUB socket publisher multicasting 100 byte messages out on a
> channel. A receiver with a ZMQ SUB socket is receiving data on that
> channel.
> I have set the ZMQ_RECOVERY_IVL = 1000 ms for the publisher and the
> subscriber. If I set ZMQ_RECOVERY_IVL = 0 or 1 ms on the subscriber I
> barely
> get any messages.
>

Setting 0 will give unreliable delivery and an indication to your network
quality.



> If I set ZMQ_RECOVERY_IVL = 1000 ms and ZMQ_RATE = 200000 kb/s on both
> publisher and subscriber, and publish these 100 byte messages at ~ 350000
> messages per second, I notice that the subscriber just hangs/pauses after
> receiving a few messages. After around 30-40 seconds it recovers from the
> pause and starts receiving messages again. The thread dump does not show
> any
> blocks.
>

The pauses are when the reliability breaks and the socket attempts to
resynchronise with the publisher.


> If I set ZMQ_RATE = 160000 kb/s and run the same scenario as before
> limiting
> my receiving rate to ~180000 messages per second, I don't get any pauses
> and
> also get all my published messages reliably.
>

There are a few options,

1)  Implement a coarse grain rate limiter when feeding the ZMQ socket.

2)  Verify hardware capability with OpenPGM test tools.

3)  Try altering the PGM parameters, for example larger APDUs up to 64KB
deliver greater reliability than smaller high frequency packet counts.

-- 
Steve-o
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20130618/bc264f5a/attachment.htm>