[HTTPCLIENT-1187] CachingHttpClient - Erroneous revalidation response date leads to a response not being properly consumed / connection held

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 4.1.3
• Fix Version/s: 4.2 Final
• Component/s: HttpCache
• Assignee: Unassigned
• Reporter: James Todd
• Created: 26/Apr/12 11:29
• Updated: 05/Oct/13 19:42
• Resolved: 08/May/12 20:00

Description

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)