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

[Ilja Golshtein]

Hi Pieter

29.10.2011, 02:50, "Pieter Hintjens" <ph at imatix.com>:
> This discussion was quite polarised. Users want monitoring, but devs
> argue that monitoring is a Bad Thing.

I am definitely a user ;)

To be honest I don't believe monitoring is bad in general.

The only reason comes to my mind to call it "Bad" is performance consideration 
(performance is my top priority, so I understand this point of course)
Anything else?

> Here is my best advice:
>
> * do not use HWMs or monitoring to control flow

Agree that current facilities do not allow to do it effectively.

> * use explicit credit-based flow control when it's needed: e.g.
> http://unprotocols.org/blog:15

Thanks.
Nice code.

> * elsewhere, use a HWM of 1000 or so (new default value)

Not sure I understand how it is possible to suggest HWM value regardless of application specific.

> * when you want explicit queue management, do this in user space by
> pulling messages off 0MQ and storing them in your own queue structure

Yes, we do pure man flow control at application level.
It is acceptable but not perfect, and I believe it would be put inside 0mq eventually.

Though right now I am focused on monitoring, not control things.
I need a way to obtain queues sizes to maintain my SNMP counters.

Could you suggest better interface than getsockopt?
Any ideas how to handle multiple peers (at least from API standpoint)?

Thanks.

-- 
Best regards,
Ilja Golshtein.