[zeromq-dev] Apparent queuing on PUB/SUB fan-in despite HWM=1
rossabri at hotmail.com
Thu May 12 00:32:22 CEST 2011
So guys, I have some evidence for my claims. I can give it to you in any combination of the following ways:
1) Python code and a shell script that implements a PUB/SUB connection pattern similar to mine where intermediate nodes introduce realistic processing delays2) Data (CSV files) generated by running the Python code/shell scripts3) SciPy code that walks on the data and makes pretty graphs4) JPEGs of the pretty graphs.
AFAICT, the bottom line is that (!!!) despite HWM=1 (!!!) on both sides of my PUB/SUB sockets there can be significant end-to-end latency, and that latency tends to grow with time. This behavior is consistent with intermediate message queuing, something the HWM is -- at least in my understanding -- supposed to prevent.
This result is very preliminary. I concede that I may still be missing something dramatic.
> From: ph at imatix.com
> Date: Wed, 11 May 2011 18:46:03 +0200
> To: zeromq-dev at lists.zeromq.org
> Subject: Re: [zeromq-dev] Apparent queuing on PUB/SUB fan-in despite HWM=1
> On Wed, May 11, 2011 at 6:36 PM, Dirkjan Ochtman <dirkjan at ochtman.nl> wrote:
> > On Wed, May 11, 2011 at 18:25, Pieter Hintjens <ph at imatix.com> wrote:
> >> Did you set the HWM _before_ connecting and binding? If you set it
> >> afterwards, it has no effect. (Rather, it has effect only on future
> >> binds and connects).
> > Heh. Can we make that assert in some next release?
> That was discussed at yesterday's meeting. The answer is "no", because
> it's legal to set the HWM for future connects & binds. What's lacking,
> I think most will agree, is any way to inspect the queue sizes. Also a
> hot topic, but we have some ideas.
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the zeromq-dev