>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
