James Todd created HTTPCLIENT-1187:
--------------------------------------
Summary: CachingHttpClient - Erroneous revalidation response date
leads to a response not being properly consumed / connection held
Key: HTTPCLIENT-1187
URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1187
Project: HttpComponents HttpClient
Issue Type: Bug
Components: Cache
Affects Versions: 4.1.3
Reporter: James Todd
We have experienced a problem with CachingHttpClient when we are connecting to
a server cluster with times out of sync, and therefore providing response dates
which are out of sync.
This causes a problem because during cache revalidation, if it gets a
revalidation response which is deemed "too old" it will make a second
unconditional request (as per the spec i believe). The issue is that the first
response isn't properly consumed so that the connection remains open. Its file
handle remains and the connection is never released back to the pool, so the
pool eventually fills up.
This can be fixed by ensuring the first response is consumed, e.g. replace
CachingHttpClient line 717 with -
if (respDate.before(entryDate)) {
try {
// MUST consume the entity if this response will not be used so
that connection is released
EntityUtils.consume(backendResponse.getEntity());
}
catch (IOException e) {
log.warn("Problem consuming old validation response");
}
return true;
}
The issue can be reproduced / tested using a HttpResponseInterceptor that
randomly changes the Date header (and hitting a page that both allows
revalidation and changes content)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
