[zeromq-dev] Exploring 0mq 3.0 - lack of monitoring

Andrew Hume andrew at research.att.com
Mon Oct 31 15:31:35 CET 2011


really?
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.

	andrew

On Oct 31, 2011, at 12:48 AM, Ilja Golshtein wrote:

> Hello
> 
> 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?
> 
> Thanks.
> 
> -- 
> Best regards,
> Ilja Golshtein.
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev


------------------
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...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20111031/94a012cc/attachment.htm>


More information about the zeromq-dev mailing list