[
https://issues.apache.org/jira/browse/HTTPCLIENT-1299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Leigh reopened HTTPCLIENT-1299:
-------------------------------------
Similar code was also introduce in HttpClient 4.2.3 CacheEntryUpdater.java that
is still present in 4.2.4.
A call to CachingHttpClient#negotiateResponseFromVariants
calls getUpdatedVariantEntry, which
calls BasicHttpCache#updateVariantCacheEntry, which
calls CacheEntryUpdater#updateCacheEntry, which
calls Resource.dispose() for the matchedEntry.
Then CachingHttpClient#negotiateResponseFromVariants
calls tryToUpdateVariantMap, which
calls BasicHttpCache#reuseVariantEntryFor, which eventually
calls BasicHttpCache#doGetUpdatedParentEntry, where
the entry variable is bound to the already disposed matchedEntry, which
causes the FileNotFoundException on copy.
I suggest that BasicHttpCache#doGetUpdatedParentEntry be restored to 4.2.2
behaviour, using the existing entry and fall back to the parent entry, and be
changed to the following :
HttpCacheEntry src = existing;
if (src == null) {
src = entry;
}
Resource oldResource = entry.getResource();
Resource resource = resourceFactory.copy(requestId, src.getResource());
Map<String,String> variantMap = new
HashMap<String,String>(src.getVariantMap());
variantMap.put(variantKey, variantCacheKey);
return new HttpCacheEntry(
src.getRequestDate(),
src.getResponseDate(),
src.getStatusLine(),
src.getAllHeaders(),
resource,
variantMap);
I suggest that CacheEntryUpdater#updateCacheEntry be changed to the following:
if (response.getStatusLine().getStatusCode() !=
HttpStatus.SC_NOT_MODIFIED)
throw new IllegalArgumentException("Response must have 304 status
code");
Header[] mergedHeaders = mergeHeaders(entry, response);
Resource resource = resourceFactory.copy(requestId,
entry.getResource());
return new HttpCacheEntry(
requestDate,
responseDate,
entry.getStatusLine(),
mergedHeaders,
resource);
This restores the 4.2.2 behaviour of waiting for the gc to queues the
CacheEntry as unreachable and ManagedHttpCacheStorage#cleanResources() is
called before the entries are actually disposed.
> FileNotFoundException on Cached Variant
> ---------------------------------------
>
> Key: HTTPCLIENT-1299
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1299
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: Cache
> Affects Versions: 4.2.3
> Environment: OpenJDK 64-Bit Server VM (6b24-1.11.5-0ubuntu1~12.04.1)
> Reporter: James Leigh
> Labels: regression
> Fix For: 4.2.4, 4.3 Beta1
>
>
> This bug was introduced in org.apache.http.impl.client.cache.BasicHttpCache
> in 4.2.3.
> cacheAndReturnResponse takes the response and passes it to storeInCache. It
> then calls generateResponse with the *same* response resource. The problem is
> that storeInCache passes the resource to doGetUpdatedParentEntry, which makes
> a copy and *deletes* the resource it was passed (oldResource).
> This did not occur in 4.2.2 because in 4.2.2 doGetUpdatedParentEntry did not
> delete the resource. If the resource is being deleted after it is copied in
> 4.2.3, then it must not be used to generateResponse.
> Here is a stack trace with line numbers.
> BasicHttpCache.doGetUpdatedParentEntry(String, HttpCacheEntry,
> HttpCacheEntry, String, String) line: 202
> BasicHttpCache$1.update(HttpCacheEntry) line: 119
> ManagedHttpCacheStorage.updateEntry(String, HttpCacheUpdateCallback)
> line: 134
> BasicHttpCache.storeVariantEntry(HttpHost, HttpRequest, HttpCacheEntry)
> line: 128
> BasicHttpCache.storeInCache(HttpHost, HttpRequest, HttpCacheEntry)
> line: 96
> BasicHttpCache.cacheAndReturnResponse(HttpHost, HttpRequest,
> HttpResponse, Date, Date) line: 265
> CachingHttpClient.handleBackendResponse(HttpHost, HttpRequest, Date,
> Date, HttpResponse) line: 919
> CachingHttpClient.callBackend(HttpHost, HttpRequest, HttpContext) line:
> 731
> CachingHttpClient.handleCacheMiss(HttpHost, HttpRequest, HttpContext)
> line: 510
> CachingHttpClient.execute(HttpHost, HttpRequest, HttpContext) line: 436
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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]
