On Thu, 2014-04-10 at 12:20 -0400, Tad Whitenight wrote:
> Oleg,
> 
> Much thanks. I was able to track this down to HTTP entity decompression,
> which is default behavior using the HttpClientBuilder API.
> Thus anyone consuming compressed entities verbatim (e.g. for storage or
> retransmission) should investigate the disableContentCompression option
> when upgrading.
> 
> Thanks,
> Tad
> 
> 

Tad,

This sounds like a known issue [1] fixed in 4.3.3. Are you using the
latest stable HC release?

Oleg

[1] https://issues.apache.org/jira/browse/HTTPCLIENT-1461

> On Thu, Mar 13, 2014 at 8:26 AM, Oleg Kalnichevski <[email protected]> wrote:
> 
> > On Wed, 2014-03-12 at 14:13 -0400, Tad Whitenight wrote:
> > > When upgrading from HttpClient 4.2 to the new APIs (no deprecated use) in
> > > 4.3 I'm observing a 25-30ms increase in average response latency. Anyone
> > > else observe this or have configuration suggestions while upgrading? I
> > see
> > > that RequestConfig.isStaleConnectionCheckEnabled is enabled by default,
> > but
> > > this appears to be for good reason.
> > >
> >
> > 4.3 performed better than 4.2 in my tests, albeit not by a great margin.
> >
> > > Were default client parameters reevaluated between 4.2 and 4.3 or have
> > they
> > > remained the same?
> >
> > Some obscure parameters were dropped in 4.3 but the defaults should have
> > remained the same.
> >
> > > In 4.3 HttpClientBuilder makes it quite clear what the
> > > default values are. In 4.2 HttpParams may have absent/unset values, which
> > > requires looking elsewhere to determine the client behavior.
> > >
> > > Thanks,
> > > Tad
> >
> > Have you tried using deprecated classes shipped with 4.3 instead of
> > 4.2?
> >
> > Oleg
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [email protected]
> > For additional commands, e-mail: [email protected]
> >
> >



---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to