On Fri, 2021-03-12 at 00:43 -0800, Ryan Schmitt wrote: > OK, I found it. It looks like the default was changed from 2000ms to > null > (disabled) in the move to 5.x. This is a promising line of > investigation > for me to pursue; I'll report back with what I find. >
I was just about to say that. I remember making that change quite early in the 5.0 development phase. This might be it. Oleg > On Fri, Mar 12, 2021 at 12:34 AM Ryan Schmitt <[email protected]> > wrote: > > > I found changes related to HTTPCLIENT-2094, but it seems to me like > > the > > default value for `validateAfterInactivity` is `null` and has been > > for > > years. Is there something in the classic client (not the fluent > > client) on > > 4.5.13 that enabled connection validation by default? > > > > On Fri, Mar 12, 2021 at 12:18 AM Ryan Schmitt <[email protected]> > > wrote: > > > > > What you're saying about the idle connection validation interval > > > is > > > interesting. Is this the `validateAfterInactivity` setting > > > defined in > > > `PoolingHttpClientConnectionManager`? Are the exceptions caused > > > by the > > > client trying to reuse a connection that's been closed, or half- > > > closed? I > > > had a hunch that something like this could be happening, but I > > > couldn't see > > > how it was possible, particularly for the classic client. (I've > > > only > > > actually seen this sort of issue with async clients.) > > > > > > On Thu, Mar 11, 2021 at 6:58 PM Carter Kozak <[email protected]> > > > wrote: > > > > > > > Is there any way you could reproduce the latency change and > > > > failures in > > > > a synthetic environment? If you could share a reproducer it > > > > would be > > > > incredibly helpful. > > > > > > > > I recall some changes to the idle connection validation > > > > interval default > > > > value, if the value isn’t set or the feature is disabled, > > > > connections > > > > closed by remote servers will result in > > > > NoHttpResponseExceptions. Bear in > > > > mind the check it triggers can cost a full millisecond on every > > > > request. > > > > > > > > -Carter > > > > > > > > > On Mar 11, 2021, at 9:45 PM, Gary Gregory < > > > > > [email protected]> > > > > wrote: > > > > > Also note that 5.1 just hit Maven Central. > > > > > > > > > > Gary > > > > > > > > > > > On Thu, Mar 11, 2021 at 9:39 PM Ryan Schmitt < > > > > > > [email protected]> > > > > wrote: > > > > > > We override (and test) most or all of the timeouts. The > > > > > > calls in > > > > question > > > > > > don't seem to be taking long enough to be getting timed > > > > > > out. > > > > > > > > > > > > > On Thu, Mar 11, 2021 at 6:09 PM Gary Gregory < > > > > > > > [email protected]> > > > > wrote: > > > > > > > Maybe a change in default timeouts from infinite to 1 or > > > > > > > 2 minutes? > > > > > > > > > > > > > > Gary > > > > > > > > > > > > > > On Thu, Mar 11, 2021 at 9:00 PM Ryan Schmitt < > > > > > > > [email protected]> > > > > wrote: > > > > > > > > On Saturday we rolled out a company-wide upgrade from > > > > > > > > Apache client > > > > > > > 4.5.13 > > > > > > > > to 5.0.3, and yesterday we ended up rolling it back due > > > > > > > > to several > > > > > > > services > > > > > > > > reporting significant increases in client-side latency > > > > > > > > and request > > > > > > > failures > > > > > > > > due to NoHttpResponseException. Can someone suggest a > > > > > > > > good place to > > > > start > > > > > > > > looking for the root cause? > > > > > > > > > > > > > > ------------------------------------------------------- > > > > > > > -------------- > > > > > > > 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] > > > > > > > > > > > > > ------------------------------------------------------------- > > > > -------- > > > > 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]
