[zeromq-dev] Exploring 0mq 3.0 - lack of monitoring
andrew at research.att.com
Mon Oct 31 15:31:35 CET 2011
i care about monitoring.
and while i have stated here repeatedly that it is a significant pain in the arse that
zeromq won't give me any idea of teh queue length (and please, we udnerstand
all about the necessary imprecisions involved -- there is no earthly reason
why an estimate couldn't be provided!), i drank the kool-aid and did app-level monitoring
and have honestly never looked back.
i 'm sure it has a performance impact, but it seems insignificant compared to all the other
work going on.
i do the monitoring in perhaps an odd way, which i could talk about separately,
but still flushing messages through a quick recv/send loop seems effcicient to me.
On Oct 31, 2011, at 12:48 AM, Ilja Golshtein wrote:
> 31.10.2011, 03:24, "Pieter Hintjens" <ph at imatix.com>:
>> * use explicit app-level queues where it makes sense, and monitor those myself
> Pieter, people who don't care about monitoring can follow your advice, but they would not
> because they don't care.
> People who care about monitoring actually cannot,
> because suggested approach affects performance in terrible way.
> That why I've started this thread.
> Regarding getsockopt. Do you believe any attempt to expose peer-specific info
> at API layer is not acceptable?
> Best regards,
> Ilja Golshtein.
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
Andrew Hume (best -> Telework) +1 623-551-2845
andrew at research.att.com (Work) +1 973-236-2014
AT&T Labs - Research; member of USENIX and LOPSA
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the zeromq-dev