Connection pooling for WebSocket connections?

[Ali Akhtar]

With Webservers, it would be very important to be able to close requests that have gone idle, in order to not keep the connections open.

Any ideas on what would be the best way to implement a connection pool for taking care of this? Ideally it should update the connection's activity timer each time anything is sent / received. If a connection hasn't been active for say, 5 seconds, it should be closed.

This would probably require keeping a map of WebsocketServer instances, but in order to time out the ones which have been inactive, it would have to loop over the map. Its probably not a good idea to do that within the main event loop. Should there be a separate thread which handles looping over / closing the expired connections?

[Ali Akhtar]

Sorry, webservers = websockets (I've been up for far too long) ;)

--
You received this message because you are subscribed to a topic in the Google Groups "vert.x" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/vertx/l-q3dZLMHLs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to vertx+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jordan Halterman]

Whether you can do it in the main loop depends on how many connections you have, but its usually fine. Something I've done in the past is this: set a single frequent (e.g. 10 or 100 milliseconds) periodic timer and store connections in a sorted data structure (maybe a List or SortedMap) sorted by last active time (this can usually be done quickly). When the timer expires, iterate through the sorted data structure, closing connections until you reach the first connection that hasn't expired. Presumably it doesn't matter if connections timeout exactly at 10 seconds (or whatever), so you can conserve resources by using a single imprecise periodic timer (not that normal timers are precise anyways). If you can manage it this way then you only iterate through connections that have expired.

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.

[Tim Fox]

I'm a bit confused about whether we're talking about websockets or webservers here, but Vert.x 3 has an idle timeout property which allows inactive connections to be automatically timed out.

[Ali Akhtar]

We are talking about Websockets. Does the idle timeout property apply to websocket connections? I.e if no messages are sent/received for the specified time, the connection is closed, but any messages sent/received reset the timer? That would be really fantastic, if so!

Thanks.

[Tim Fox]

On 24/03/15 09:20, Ali Akhtar wrote:

We are talking about Websockets. Does the idle timeout property apply to websocket connections? I.e if no messages are sent/received for the specified time, the connection is closed, but any messages sent/received reset the timer? That would be really fantastic, if so!

I think it should apply to any TCP connections on the web server, whether they've been upgraded to websocket or not.

[Ali Akhtar]

I will write a unit test to confirm. Should sending / receiving messages reset the timer, in theory?

[Tim Fox]

On 24/03/15 09:26, Ali Akhtar wrote:

I will write a unit test to confirm. Should sending / receiving messages reset the timer, in theory?

Yes it should.

(Beware testing with browsers, they probably send ping packets which would prevent the connection timing out).

[Ali Akhtar]

I will use the beloved HttpClient to test. :)

[Ali Akhtar]

If browsers send ping packets though, that probably defeats the purpose.. and would require that a custom connection pool be written anyway. Right?

[Tim Fox]

On 24/03/15 09:50, Ali Akhtar wrote:

If browsers send ping packets though, that probably defeats the purpose.. and would require that a custom connection pool be written anyway. Right?

I'm not sure I follow

[Ali Akhtar]

Well, what you would want is to only keep the websocket connections active while the user is interacting with the page. If the user opens the page, and then keeps the tab for hours while he's doing other things, then that connection should be closed so it doesn't take up server resources.

So ideally, only real packets being sent / received should count as activity, and not ping packets, for websockets .

[Tim Fox]

On 24/03/15 09:53, Ali Akhtar wrote:

Well, what you would want is to only keep the websocket connections active while the user is interacting with the page. If the user opens the page, and then keeps the tab for hours while he's doing other things, then that connection should be closed so it doesn't take up server resources.

So ideally, only real packets being sent / received should count as activity, and not ping packets, for websockets .

I would disagree, the whole reason browsers send ping packets is to stop servers timing out connections ;)

Not respecting that could break all kinds of websocket applications. E.g. someone might like to keep a browser window open with a news feed application in it.

[Ali Akhtar]

I guess it depends on what kind of application you're building, because for a lot of other apps, such as games, if the user minimizes the window or walks away from the computer, the connection should be closed to prevent it hogging resources.

So I would have to write my own connection pool in order to deal with that use case? Any suggestions on how to do that?

[Ali Akhtar]

I've run a unit test to see if the connection is closed: https://gist.github.com/aliakhtar/602ee81f58046cdcfb9b

Unfortunately it isn't. I've left the test running for 5 minutes and the close handlers aren't called.

Am I missing anything?

Thanks.

[Tim Fox]

Please can you open an issue so this gets added to the queue?

[Kirk Stork]

If some kind of arbitrary connection-closing policy is adopted, there needs to be a way for developers to opt out of that policy. I can think of many use cases where closing out based on inactivity would be countrary to an application's purpose. Sometimes "Not clicking" is not the same as "not using".