Thank you for your help Oleg, very much appreciated.

-----Original Message-----
From: Oleg Kalnichevski [mailto:ol...@apache.org] 
Sent: Tuesday, September 15, 2015 8:18 AM
To: HttpClient User Discussion
Subject: Re: GZIP encoding, EOF detector & leaked connections

On Tue, 2015-09-15 at 08:10 -0700, David Ayre wrote:
> Hi Oleg,
> 
> I think you are probably right... we can read the entity fully, it's just 
> that the connection is never released... & we have very little control over 
> these remote servers.   The only solution i can think of in this case is to 
> disable content compression, don't accept gzip.
> 
> Are there any other solutions you can think of ?
> 

(1) Disable automatic content decompression, (2) add 'Accept-Encoding:
gzip' using a protocol interceptor or manually (3) decode content manually.

Oleg  

> David
> 
> -----Original Message-----
> From: Oleg Kalnichevski [mailto:ol...@apache.org]
> Sent: Tuesday, September 15, 2015 12:33 AM
> To: HttpClient User Discussion
> Subject: Re: GZIP encoding, EOF detector & leaked connections
> 
> On Mon, 2015-09-14 at 09:48 -0700, David Ayre wrote:
> > I'm using httpclient 4.4.1 with Jersey 2.19 and have spent some time 
> > troubleshooting a problem with http connections to a specific server A 
> > leased from the  PoolingClientConnectionManager which are never made 
> > available again because they are never released.   Our per route for A 
> > maxes out and a portion of our app locks up within the connection manger 
> > waiting for an available connection.
> > 
> > Connections are properly released when i connected to a different server B, 
> > so i compared the calls from both A & B and the one difference i noticed 
> > was the successful one to B was not getting a compressed response.
> > 
> > When connecting to server B, the EOF detector released the connection to 
> > the connection manager successfully, for A with a compressed response, the 
> > EOF detector never releases the connection.
> > 
> > When i enable the "contentCompressionDisabled" flag manually for A within 
> > the HttpClientBuilder, the connection to server A works as the EOF detector 
> > correctly releases the connection.
> > 
> > Should gzip compression affect the ability for the EOF detector to release 
> > the connection back to the pool ?   If not, then i think this may be a bug.
> > 
> > David
> 
> David
> 
> While this may well be a bug in HC I think it is more likely that GZIP 
> content stream is incorrectly terminated which causes HC to assume that more 
> data is still to come.
> 
> Oleg
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
> For additional commands, e-mail: httpclient-users-h...@hc.apache.org
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
> For additional commands, e-mail: httpclient-users-h...@hc.apache.org
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
For additional commands, e-mail: httpclient-users-h...@hc.apache.org

Reply via email to