[zeromq-dev] cleaning up TCP sockets

[Felipe Cruz]

Maybe this can be done with the monitor api with a new
ZMQ_EVENT_INACTIVITY_TIMEOUT ?


2013/3/21 Joel Lauener <Joel.Lauener at cern.ch>

> >Unless you're spawning more and more virtual machines, the number
> >of stuck clients cannot exceed the number of normal live clients, right?
> >So you're not going to experience any leak of server resources.
>
> It's a bit more dynamic than that and we can have many clients per
> VM/server/front-end. The number of 1500 clients is just an average. What
> scare us is massive creation of stuck clients through some broken script,
> for example.
>
> >Now, we could make ROUTER sockets smarter about this, I think. Simply:
> >if there's no activity on a connection, after some timeout, kill it.
> >If the client is just doing other things, it will reconnect when there's
> new activity. If the client is dead, it won't.
>
> This is exactly what we need :) Another way would be to allow closing a
> socket by providing the identity of the peer. In short it would be
> interesting, at least for us, to have more control over the sockets behind
> a ROUTER.
>
> -----Original Message-----
> From: zeromq-dev-bounces at lists.zeromq.org [mailto:
> zeromq-dev-bounces at lists.zeromq.org] On Behalf Of Pieter Hintjens
> Sent: 21 March 2013 14:58
> To: ZeroMQ development list
> Subject: Re: [zeromq-dev] cleaning up TCP sockets
>
> On Thu, Mar 21, 2013 at 2:27 PM, Joel Lauener <Joel.Lauener at cern.ch>
> wrote:
>
> > We are migrating an infrastructure with ~3500 active servers and ~1500
> > active clients from CORBA to ZMQ. We only provide the library, our
> > users implement the clients/servers on top of it and deploy were/how
> > they want. We also have many combinations of hardware/OS: low level
> > front-ends, middle tier servers and workstations. As you can see our
> > system is quite open and complex :/
> >
> > By "stuck client" I mean a client for which the process is blocked
> (deadlock, OS problem, hardware problem) but for which the TCP stack is
> still alive. Of course this is very unlikely to happen, but from our
> experience it can happen. For example a virtual machine going into
> hibernation can have very nasty  behaviour.
> >
> > This is not an hard requirement, just a nice to have. I guess the only
> (clean) way is to have one ZMQ socket per client instead of a single ROUTER.
>
> Nice to hear that CERN is moving onto ZeroMQ in a large way. :-)
>
> Unless you're spawning more and more virtual machines, the number of stuck
> clients cannot exceed the number of normal live clients, right?
> So you're not going to experience any leak of server resources.
>
> Now, we could make ROUTER sockets smarter about this, I think. Simply:
> if there's no activity on a connection, after some timeout, kill it.
> If the client is just doing other things, it will reconnect when there's
> new activity. If the client is dead, it won't.
>
> Regards,
> Pieter
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20130321/79f3aae0/attachment.htm>