You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by "James Todd (JIRA)" <ji...@apache.org> on 2012/04/26 13:31:17 UTC
[jira] [Created] (HTTPCLIENT-1187) CachingHttpClient - Erroneous
revalidation response date leads to a response not being properly consumed
/ connection held
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: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[jira] [Resolved] (HTTPCLIENT-1187) CachingHttpClient - Erroneous
revalidation response date leads to a response not being properly consumed
/ connection held
Posted by "Oleg Kalnichevski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Oleg Kalnichevski resolved HTTPCLIENT-1187.
-------------------------------------------
Resolution: Fixed
Fix Version/s: 4.2 Beta2
Fix committed to SVN trunk and the 4.1.x branch. Please re-test.
Oleg
> 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
> Fix For: 4.2 Beta2
>
>
> 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: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org