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.
On Wednesday, August 3, 2016 at 2:10:30 PM UTC+2, Julien Viet wrote: > > Alex, this is the Netty group, not the Vert.x group :-) > > On Aug 3, 2016, at 2:20 PM, Alexander Lehmann <[email protected] > <javascript:>> wrote: > > 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. > > > > On Wednesday, August 3, 2016 at 5:05:57 AM UTC+2, Luke Daley wrote: >> >> 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. >> > > -- > 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 [email protected] <javascript:>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/netty/8ef3beac-e88b-42a8-a260-3a720b5757f4%40googlegroups.com > > <https://groups.google.com/d/msgid/netty/8ef3beac-e88b-42a8-a260-3a720b5757f4%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > > > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/netty/d03470bb-1b36-47a4-a129-4ebd3a4dc8b3%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
