[
https://issues.apache.org/jira/browse/HTTPCLIENT-427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb reopened HTTPCLIENT-427:
-----------------------------
I think there is still a minor issue with the CacheEntry class.
It contains the field:
private final byte[] body;
However, this is exposed by both the constructor and getBody(), neither of
which copy the array.
As it stands, the class is not @Immutable, because the body array can be
changed externally.
Simplest solution is to copy the array.
Also, the CacheInvalidator class is definitely not @Immutable, because the
cache can be upated.
It is @ThreadSafe, so long as the cache implementation is @ThreadSafe
The AtomicLong fields in CachingHttpClient don't need to be volatile; also I
think the class is now @ThreadSafe, so long as the responseCache is.
> Implement a cache to perform real request only when needed
> ----------------------------------------------------------
>
> Key: HTTPCLIENT-427
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-427
> Project: HttpComponents HttpClient
> Issue Type: Improvement
> Components: HttpClient
> Environment: Operating System: Linux
> Platform: PC
> Reporter: Marc Guillemot
> Fix For: 4.1 Alpha2
>
> Attachments: caching_client.zip,
> HTTPCLIENT-427-Immutable-CacheEntry2.patch,
> HTTPCLIENT-427-immutable-cachenentry.patch, httpclient-cache.zip
>
>
> Browsers may cache received content according to the values of different
> response headers. It would be great if HttpClient could do the same.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
