Hi Willy, we see the same effect in our environment here as well. We are not sure if this is related to a still open Websocket connection.
Do you think that a timeout tunnel 1h # timeout to use with WebSocket and CONNECT in the configuration will help to terminate these processes after the specified timeout. If there is a chance i will give it a try in our production. Greetings Stefan On Tue, Jan 28, 2014 at 11:28 PM, Willy Tarreau <[email protected]> wrote: > On Tue, Jan 28, 2014 at 10:16:39PM +0000, Wei Kong wrote: > > Thanks. Looks like it is websocket connections for us too. So is killing > > the process the only way? > > It depends if you're willing to kill your websocket connections or not. At > some point they will disappear since the old process does not accept any > new connection. However I understand it can be long, especially with some > setups using 24h as the timeout, resulting in dead clients maintaining > their connection for an artificially long time! > > There was a feature I wanted to implement for client-side HTTP keep-alive > which would consist in reducing the keep-alive timeout and disabling keep- > alive for new requests over existing connections, so that these ones would > vanish much faster. Maybe we could do something like this for existing > tunnels. It's not very easy if we want to consider existing silent > connections. > > If you really don't care about the old connections, just use -st instead > of -sf when reloading, and once the new process takes over, the old one > will go away even if it has some remaining connections. > > Willy > > > -- Stefan Majer
