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.
On Tuesday, August 9, 2016 at 2:44:03 PM UTC+10, Norman Maurer wrote: > > +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. > > > On 09 Aug 2016, at 02:08, 'Chris Conroy' via Netty discussions < > [email protected] <javascript:>> wrote: > > 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] <javascript:>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/netty/edb0d534-a5d1-42aa-8725-572d093661d1%40googlegroups.com > > <https://groups.google.com/d/msgid/netty/edb0d534-a5d1-42aa-8725-572d093661d1%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/49b72fdc-f480-4f85-a260-93d024026f96%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
