HTTP connect pooling and autoread.

[Luke Daley]

Hi,

I'm looking for some guidance on implementing HTTP client side connection pooling. I have the basics of this working, but am uncertain about handling connection termination by the server while idle.

I'm essentially using ChannelPoolMap and the default IS_ACTIVE health check on acquire and release. What I'm seeing with _some_ servers is that an idle connection is being reported as isActive() when acquired, but immediately goes inactive after performing the first write to it (i.e. effectively failing the write). 

When channels are being returned to the pool in my case, they have autoRead = false. Is this what could be causing the channel to report as active until there is a write? If so, why could it be only with some servers? Is it better practice to enable auto read before returning a channel to the pool?

Thanks in advance,

Luke Daley.

[Alexander Lehmann]

Usually the HTTP connection is handled by the vertx pool automatically (handling Keep-Alive if the server supports it).

If you are implementing the protocol yourself, that should be no problem, however you have to be sure to evaluate the Connection: keep-alive and Connection: close headers to know upfront if the connection can be used for following requests (this is more or less a problem in any http client and not limited to vert.x). If you check the connection status immediately after the response is read, it might be still open when you check but will be closed by the server immediately after that.
If the server does not support Connection: keep-alive on the specific connection, in the case where there is no Content-Length, you have consider the server closing the connection as correct behaviour and then close the connection on the client side as well.

[Julien Viet]

Alex, this is the Netty group, not the Vert.x group :-)

-- 
You received this message because you are subscribed to the Google Groups "Netty discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to netty+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/netty/8ef3beac-e88b-42a8-a260-3a720b5757f4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Alexander Lehmann]

Ah sorry, I thought I was in the vert.x group.

I am not sure how the http works in netty, but basically the same considerations should apply,you have to make sure that you are using Connection: close or keep-alive and if there is no Content-Length or chunked header, you have to wait for the connection to close and do the same.

[Luke Daley]

Just to be clear, this question isn't “resolved”. The issue I have isn't about the headers to send.

I'd appreciate some guidance if anyone who has implemented HTTP connection pooling without auto read.

[Alexander Lehmann]

I am aware of that, but I cannot give any assistance about netty, I wrote the answer in the wrong group, I am very sorry about that. Please assume that I didn't write the answer in the first place, since I do not know what I am talking about.

[Chris Conroy]

It certainly shouldn't hurt to have auto-read enabled when you return the connection to the pool since it won't actually be receiving any data to receive until after you write another request.

I'd double check that you aren't actually receiving any data when the channel is in the pool: you could try running with auto-read on and have a special handler that logs an error if the channel is not currently borrowed from the pool. It could be that the server is closing the connection due to detecting your client as a slow reader of some data that wasn't fully consumed before returning to the pool?

[Norman Maurer]

+1

That said even if auto-read is on you may not receive a notification that the remote peer closed the connection before you actual try to write something. So your client need to be aware of it and reconnect in this case.

-- 
You received this message because you are subscribed to the Google Groups "Netty discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to netty+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/netty/edb0d534-a5d1-42aa-8725-572d093661d1%40googlegroups.com.

[Luke Daley]

Alexander,

Apologies if my reply seemed rude; that wasn't my intention. I appreciate you taking the time to respond. I just wanted to make it clear to anyone else following that it wasn't “resolved”.

[Luke Daley]

Ok, I'll go in that direction. Thanks.

Out of interest, is there any potential impact of having a few thousand open connections with auto read on “idling” in the pool? My understanding is that this means that there's effectively a poll going on for each of these connections.