Martin,
Why not simply post a warning in the manual that using this information for
business logic is severely disrecommended. You cannot really 'lock down'
functionality, and abuse is other a relative point of view.
It would be more useful imo to open up the data in a usable for and clearly
expl
On 12/23/2010 12:47 AM, Paul Colomiets wrote:
> Or even maybe socket type, which could look like:
>
> sock = ctx.socket(zmq.MONITOR)
> sock.bind('inproc://connections')
> realsock = ctx.socket(zmq.REQ)
> realsock.connect('inproc://connections')
> realsock.send("active")
>
Hi Juan,
> I will insist in the observability matter. If you find inappropriate or
> unproductive my insistence, just tell me.
No problem. I'm cc'ing the list btw.
> > However, what I fear is that exposing this kind of info would
> immediately result in people using it to
> > drive business l
21.12.2010, 20:32, "Martin Sustrik" :
> However, what I fear is that exposing this kind of info would
> immediately result in people using it to drive business logic rather
> then using it for system monitoring. That in turn breaks the
> "not-connected" design of 0MQ, severely hurts scalability
Juan,
> I understand it is a messaging middleware, but wouldn't it be a good
> thing if you can monitor the state of the middleware? :
> - state of connection
> - visibility of peers
> - occupation of internal queues
> - any other already known data
There's an internal monitoring
2010/12/21 Steven McCoy
> On 21 December 2010 21:12, Juan Carlos Franzoy wrote:
>
>> Is there any plan to add some observability to ZMQ library? Something like
>> a getsockopt that list the visibility state of the endpoints the socket is
>> connected to?
>>
>>
> The general reply is that 0mq is
On 21 December 2010 21:12, Juan Carlos Franzoy wrote:
> Is there any plan to add some observability to ZMQ library? Something like
> a getsockopt that list the visibility state of the endpoints the socket is
> connected to?
>
>
The general reply is that 0mq is a messaging middleware not a streami
Hello. First of all, thank for reading and congratulations for ZMQ.
We are considering using ZMQ to implement a communication library for all
our applications, which are almost always distributed. We make telephonic
applications. All our clients require us to inform, usually through SNMP,
the stat
