shinseongsu opened a new pull request, #738: URL: https://github.com/apache/httpcomponents-core/pull/738
Follow-up to #735 for [HTTPCLIENT-2437](https://issues.apache.org/jira/browse/HTTPCLIENT-2437). `LaxConnPool` already completes the future of an expired request, but only when that request is at the head of the queue. `PerRoutePool#servicePendingRequests` stops at the first request it cannot serve, so when the head request has not expired yet, expired requests behind it are not failed by `closeExpired()` or `closeIdle()`. This shows up when lease requests on the same route use different `connectionRequestTimeout` values. With a pool of 1, request B (1 minute) and then request C (100 ms) waiting behind a leased connection, C is still pending after `closeExpired()`. `StrictConnPool` fails C in the same case, as `processPendingRequests()` walks the whole queue. `enumAvailable()` now also calls `validatePendingRequests()`, which checks every pending request. Tests: the new `TestPoolPendingRequestExpiry` case fails on master for `LAX` only and passes with the change. httpcore5 verify: 2011 tests, 0 failures. 5.4.x has the same code. I have the same change on a 5.4.x branch, with the test using the real clock as in the #735 cherry-pick; it fails before the change and passes after (httpcore5 verify: 1264 tests). Should I open a separate PR for 5.4.x, or would you prefer to cherry-pick it? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
