Maybe this can be done with the monitor api with a new ZMQ_EVENT_INACTIVITY_TIMEOUT ?
2013/3/21 Joel Lauener <[email protected]> > >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: [email protected] [mailto: > [email protected]] 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 <[email protected]> > 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 > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev >
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
