Hi Martin,
I found out that it was a stupidity on my part. Here is how I got into this
confusing situation that misled me to speculate batching was causing the delay.
A publisher process outside the firewall needs to publish message via a ZMQ_PUB
socket. The subscribers are within the
I have an application that needs to send out a message as soon as possible
without waiting for the optimistic batching. Latency is more important than
message throughput. Is there a switch I can use with zmq_setsockopt to disable
batching? I looked at the man page but couldn't find anything
ch...@chriswongstudio.com said:
I have an application that needs to send out a message as soon as possible
without waiting for the optimistic batching. Latency is more important than
message throughput. Is there a switch I can use with zmq_setsockopt to
disable batching? I looked at the
Ah shoot. I really need that. I'll try to resurrect it. What would be a good
alternative name for it?
Maybe it should come back as a socket option?
Thoughts?
Chris
On Apr 15, 2010, at 5:44 PM, Martin Lucina wrote:
ch...@chriswongstudio.com said:
I have an application that needs to send
ch...@chriswongstudio.com said:
Ah shoot. I really need that. I'll try to resurrect it. What would be a
good alternative name for it?
Maybe it should come back as a socket option?
Thoughts?
The original zmq_flush() and the accompanying ZMQ_NOFLUSH flag to send was
really more of a
I was stumbling around the code and found a out_batch_size in config.hpp. I
wonder what would happen if I lower that value. :-)
A hint is better than nothing, I suppose. I don't mind that it's getting sent
out in the background I/O as soon as possible without a hard guarantee at the
app
Chris,
0MQ does not batch when there's nothing to batch. The only situation
when batching happens is when network is not fast enough to transport
messages. In such case messages are queued and sent later on in batches
to improve throughput.
I was stumbling around the code and found a
