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 firewall. So, I experiment that with the publisher bind to 5555 and have the subscribe connect to the publisher at 5555. 1. I started the subscriber first (naturally). 2. Started the publisher 3. Subscriber shows that it only received about nine hundreds out of a thousand. At first, I was just sending the string "Hello" repeatedly 1000 times. After prefixing the string with an integer, I noticed that I was missing about the first 100 messages instead of the last 100. That concludes that it wasn't batching that delayed the delivery of the message. It was because of my use of bind on the publisher and connect from the subscriber that caused the connection of subscriber to the publisher delayed. This is a subtle difference that I wasn't aware of. :-) Maybe a better way to deal with this kind of problem is to use the zmq-forwarder so that both the publisher and the subscriber can both "connect" instead of bind. Thought? Chris On Apr 15, 2010, at 11:53 PM, Martin Sustrik wrote: > 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 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 thread. Just want to make sure that the >> data is not hanging around for a long time before it decides that >> it's "too long". I tried inserting a sleep in my sender application >> thread hoping that it'd give the IO thread time to send out the >> content in the buffer, but it won't don't it. The app thread slept >> as long as 15 secs. > > This looks like a bug. What exactly are you doing? > > Martin > _______________________________________________ > zeromq-dev mailing list > zeromq-dev@lists.zeromq.org > http://lists.zeromq.org/mailman/listinfo/zeromq-dev _______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
