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? On Monday, August 8, 2016 at 3:26:41 AM UTC-4, Luke Daley wrote: > > 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. > > On Wednesday, August 3, 2016 at 1:05:57 PM UTC+10, 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]. To view this discussion on the web visit https://groups.google.com/d/msgid/netty/edb0d534-a5d1-42aa-8725-572d093661d1%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
