hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Leigh (JIRA)" <j...@apache.org>
Subject [jira] [Reopened] (HTTPCLIENT-1299) FileNotFoundException on Cached Variant
Date Fri, 12 Apr 2013 19:04:16 GMT

     [ 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: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org


Mime
View raw message