[nanomsg] Re: Pub/Sub behavior
- From: Matthew Hall <mhall@xxxxxxxxxxxxxxx>
- To: nanomsg@xxxxxxxxxxxxx
- Date: Fri, 13 Nov 2015 22:26:03 -0800
On 11/13/15 11:08 AM, Charles McParland wrote:
Using tcp,
I can publish hundreds of messages and
the subscriber - which I've manually slowed down - keeps handing
me the earliest messages in order. So, are these messages getting
cached in the subscriber nanomsg stack ? Can I reach down and
flush old messages and force the subscriber to get "current"?
Hi Chuck,
I also have used nanomsg between C and Java and like the nice simple
APIs. I contributed some important security patches to jnano:
https://github.com/gonzus/jnano/pull/5
I have C code which is doing very high speed processing which can't be
allowed to bog down. For spray-and-pray mode in my code I use this:
rv = nn_send(nn_queue->conn, message, length, NN_DONTWAIT);
You can also do some slightly more sophisticated stuff:
http://nanomsg.org/v0.7/nn_setsockopt.3.html
NN_SNDBUF
NN_RCVBUF
If NN_DONTWAIT is used, packets are tossed out and nn_errno() is EAGAIN.
The buffer limits set with NN_SNDBUF are respected, plus one additional
packet is allowed. The application can apply internal backpressure from
the EAGAIN.
For automatic backpressure (i.e. blocking) just do not specify
NN_DONTWAIT, and the upstream app will slow to allow backpressure.
Another possible option would be reading everything downstream as soon
as it arrives and scheduling it for execution in a Timer Queue with a
deadline. Something like a token-bucket or leaky-bucket algorithm.
Nanomsg and ZeroMQ explicitly and deliberately eschew the more complex
queuing mechanisms because they end up being very counterproductive. In
this paper an expert explains it quite well if you didn't see this already:
http://www.imatix.com/articles:whats-wrong-with-amqp/
I found a lot of it quite obvious from my SW dev career but felt much
better knowing I wasn't the only one thinking it, and learned some
helpful details about how things can go so catastrophically wrong in our
field.
At a high level if producers and consumers have big long lasting
imbalances, the scaling between the tiers is wrong and one side needs to
be shrunk or expanded to balance the load. Trying to do otherwise ends
up causing more problems than it solves.
Matthew.
Other related posts: