Alex, this is the Netty group, not the Vert.x group :-) > On Aug 3, 2016, at 2:20 PM, Alexander Lehmann <[email protected]> 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] > <mailto:[email protected]>. > 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 > <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/BC7D95D6-FEFA-41ED-89F2-89F073DF0932%40julienviet.com. For more options, visit https://groups.google.com/d/optout.
