Closing keep-alive connection after inactivity period

[Slavik Baranov]

Hello,

Is it possible to close connections on the server after certain period of inactivity? For now unused connection aren't closed on my server for a long time, sometimes for several days. I searched for some configuration property, but didn't find one.

Thanks,

Slava

[Tim Fox]

I'm assuming you're referring to a NetServer?

If so, there is no configuration property but it's easy to add such functionality in code, something like this, off the top of my head:

vertx.createNetServer().connectHandler(function(sock) {

  var lastAccess = new Date().getTime();

  sock.dataHandler(function(data) {

    lastAccess = new Date().getTime();

  });

  vertx.setPeriodic(timeout, function(id) {

    if (new Date().getTime() > lastAccess > timeout) {

       vertx.cancelTimer(id);

       sock.close();

    }

  });

}).listen(1234, 'localhost');

[Slavik Baranov]

Tim,

thank you for reply. Actually, I've been asking about HttpServer, sorry for not being specific enough. I think, there's no connectHandler() in HttpServer.

Thanks,

Slava

четверг, 18 октября 2012 г., 21:18:23 UTC+4 пользователь Tim Fox написал:

[이세행]

Hi Tim

i use vertx version 2.0.2

i can't find connection close check code in java

how can i do ?

2012년 10월 19일 금요일 오전 2시 18분 23초 UTC+9, Tim Fox 님의 말:

[Norman Maurer]

What you mean? Could you give more details?

--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[赵普明]

When we were using vert.x 1.3.0 we have to add a IdleStateHandler to the underlying netty code in vert.x server implementation. Otherwise there is always connection leaks in our server (where the connectionMap will pile and take up a lot of memory and system connections will be exhausted in a few days)

在 2012年10月19日星期五UTC+8上午12时34分42秒，Slavik Baranov写道：

[Alexander Lehmann]

When trying out the vert.x http server with keep-alive I thought that this was actually missing from the implementation, usually the server connection is closed after a few seconds and the number of possible connection is limited with a large number.

E.g. Apache http usually has a keep-alive connect timeout of 15 seconds and allows 100 consecutive requests on one connection.

I haven't tested what happens when client closes the connection, I assume the server socket will be closed automatically then.

[Tim Fox]

Can you explain a bit more? I'm not sure I follow.

--

[Tim Fox]

Vert.x is a toolkit for creating network aware applications, not a fully fledged web server like Apache, it doesn't automatically close anything for you. If you want to close Keep-Alive connections after a timeout, that's something you'd have to code yourself.

[Alexander Lehmann]

Ok, it's called createHttpServer, so I assume people will think that is conforms to HTTP, which it doesn't quite if it is not handling keep-alive, this may not be a big issue though.

I wonder how it is possible to handle the socket connections, since the RequestHandler is based on the individual request and not on the connection.

[Tim Fox]

On 22/02/14 00:58, Alexander Lehmann wrote:

Ok, it's called createHttpServer, so I assume people will think that is conforms to HTTP, which it doesn't quite if it is not handling keep-alive,

I don't think there is anything in the HTTP spec that says a server MUST close keep alive connections after a certain time. AIUI this behaviour is entirely up to the web server.

this may not be a big issue though.

I wonder how it is possible to handle the socket connections, since the RequestHandler is based on the individual request and not on the connection.

You can get a reference to the NetSocket using request.netSocket(), which should allow you to do what you want. However, I think we could make this easier by allowing the server to be configured with a connection timeout, e.g. server.setConnectionTimeout(10000) - please feel free to add a BZ feature request if you think this is a good idea.

On Friday, February 21, 2014 4:23:50 PM UTC+1, Tim Fox wrote:

Vert.x is a toolkit for creating network aware applications, not a fully fledged web server like Apache, it doesn't automatically close anything for you. If you want to close Keep-Alive connections after a timeout, that's something you'd have to code yourself.

[Alexander Lehmann]

Turns out I should really read the rfc before quoting it, if the server chooses to keep the connection open, thats probably ok, though it may not what programmers expect.

I think the Connection Header is mandatory or at least a "should" if it doesn't do connection-close and if it is send if can stick to what the header announces. Currently vert.x doesn't send a Connection header and also doesn't honour it if the client sends one. If this is not in the scope of vert.x it might be handled by a framework like yoke (haven't tried that at all yet).

The problem with implementing the timeout on the request is as far as I understand it that the connection is not the responsibility of a single request (though the request processing may require to close the connection at the end when connection: close is received for example), but of the client-server connection that may cover more than request of course.

The flow is something like:

client -> connect
server -> accept
client -> request1
server -> response1
client -> request2
server -> response2
...
server ->close / client ->close (either one)

and either the server or the client may choose to close the connection after a request is sent/received or even inbetween in case of an error.

If using pipelining, the flow will become

client -> connect
server -> accept
client -> request1
client -> request2
server -> response1
(server may close here)
server -> response2
client -> request3
server -> response3
...
server ->close / client ->close (either one)

even in this case, the sever may have to close the connection after sending a response and ignore the next requests already sent.

With keep-alive the close of the client or server may happen seconds after the last response was received if a timeout is defined (the client will honour the timeout sent by the server if any and the server will honour the timeout if there is one and just close the connection)

[Tim Fox]

On 23/02/14 13:16, Alexander Lehmann wrote:

Turns out I should really read the rfc before quoting it, if the server chooses to keep the connection open, thats probably ok, though it may not what programmers expect.

I think the Connection Header is mandatory or at least a "should" if it doesn't do connection-close and if it is send if can stick to what the header announces. Currently vert.x doesn't send a Connection header and also doesn't honour it if the client sends one. If this is not in the scope of vert.x it might be handled by a framework like yoke (haven't tried that at all yet).

The problem with implementing the timeout on the request

I don't think anyone is suggesting implementing a timeout on the request. The current API lets you get the socket, so you can timeout on that if you want.

As mentioned before, if you'd prefer a simpler API (e.g. setTimout) on the server, please add a BZ :)

[Ryan Chazen]

I think that following the idea of 'sane defaults' is always a very good idea. Eg, if leaving everything on defaults creates an HTTP server that will eventually run out of ram and crash after a couple days, then the defaults must be changed to prevent that. Allowing configuration is great, but if the defaults create a broken application that requires those defaults to be changed for production use, then the defaults are flawed. So I don't think just a simpler API is the answer: I think there should be a timeout by default (they could be removed through configuration) to enable vert.x to work as a production server by default. Just saying "vertx is a platform, it's up to the middleware to make it reliable" feels like passing the buck - the platform should work by itself and the middleware/modules should add features, not fix bugs.

[Tim Fox]

Node.js is no different in this regard - it won't close keep-alive connections by default.

[Tim Fox]

The purpose of Vert.x core is not to include a fully featured web server (neither is it the purpose of Node.js core) - if we pushed everything into core, and had as much functionality as Apache, we'd have a huge bloated core.

If people want to create another Apache using Vert.x, that's great, it would be a great fit. But I see that as something that should be created as a Vert.x module, not something that's in Vert.x core.

On 24/02/14 08:44, Ryan Chazen wrote:

[Ryan Chazen]

Does Node.js run out of memory and crash after running for a few days? I haven't experienced that before with Node.js, but I guess it could be happening? Either way, that sounds like a bug in node.js as well then.

Also I don't think a server crashing from running out of ram in the default configuration is 'functionality from apache'. Functionality from apache is stuff like caching, or authentication, fileserving, etc etc. Things that you could put as features. 'Not crashing after a few days' does not sound like a feature. I could be way off here though and missing something.

I think if http built on top of vert.x is meant to handle connections explicitly, then there should be a 'ConnectionHandler' that needs to be set in addition to the 'RequestHandler' when you create an http server.

[Tim Fox]

Sorry... who is crashing and running out of RAM after a few days? Have I
missed part of the conversation here?

[Ryan Chazen]

赵普明 said he was crashing and I assumed the connections remaining open for days for Alexander were causing similar issues. I haven't experienced any crashes myself yet, but I'm restarting my server very regularly at the moment. Surely if the connections are never closed, eventually the server must crash ? If I've misunderstood this then ignore it.

[Tim Fox]

On 24/02/14 09:20, Ryan Chazen wrote:

赵普明 said he was crashing and I assumed the connections remaining open for days for Alexander were causing similar issues. I haven't experienced any crashes myself yet, but I'm restarting my server very regularly at the moment. Surely if the connections are never closed, eventually the server must crash ?

The server doesn't _pre-emptively_ close Keep-Alive connections but this doesn't mean connections aren't closed. Browsers will close connections when tabs are closed or during navigation. Connections will also closed when the browser closes or crashes.

[Alexander Lehmann]

I agree, for this to happen, the clients have to keep the connections open on purpose, which will not happen except in attacks (and they will keep the connection open before the first request probably).
Any well-behaved client will close the keep-alive connections after a while and then the server will close the connection as well.

My point was that the behaviour should be more like Apache, but I guess Node.js is probably a better benchmark what the should do or should be in extensions.

I have yet to figure out how to do unit tests in vert.x, if I can I will implement a few tests that show the necessary features for the server and we can decide if they are in fact necessary or should be in another scope.