hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nikola Petrov (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (HTTPCLIENT-1395) Call the storage implementation only once on a cache miss
Date Tue, 03 Sep 2013 13:21:55 GMT

     [ https://issues.apache.org/jira/browse/HTTPCLIENT-1395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Nikola Petrov updated HTTPCLIENT-1395:

    Attachment: call-storage-implementation-once-trunk.patch

Hi, Oleg

Here are two patch files for 4.2 and for trunk. I exposed the methods in the HttpCache as
you suggested. Also I added a new CacheConfig variable in trunk to control if the client should
try to ignore the response if there is a newer in the cache as described here http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.2.5
> Call the storage implementation only once on a cache miss
> ---------------------------------------------------------
>                 Key: HTTPCLIENT-1395
>                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1395
>             Project: HttpComponents HttpClient
>          Issue Type: Improvement
>          Components: HttpCache
>    Affects Versions: 4.2.5
>            Reporter: Nikola Petrov
>            Priority: Minor
>             Fix For: 4.3.1
>         Attachments: call-storage-implementation-once-4.2-branch.patch, call-storage-implementation-once.patch,
> I am trying to use the httpclient-cache component with a Cassandra backend. Everything
seems good except that HttpCacheStorage#getEntry is getting called 3 times the first time
resulting in a performance bottleneck. There might be a way to handle this in the Storage
implementation by caching the recently queried values but I think that a better place is in
the CachingHttpClient class. The current code expects zero latency to the storage backend(the
current implementations are all memory based) but here is a patch that fixes the problem.
Some notes:
> * I am using the code from the 4.2.5 release(but can port the code to the current trunk)

> * test is provided in org.apache.http.impl.client.cache.TestCachingHttpClient
> * BasicHttpCache is patched to expose methods that check if the key is found or if a
proper variant is found - without this there is no way to say if there was a real cache miss
or the specific variant is missing
> * CachingHttpClient is checking if the current HttpCache implementation is BasicHttpCache
so it can use the new methods - I didn't want to change the interface because this will add
breaking changes to the API
> * This exposes the alreadyHaveNewerCacheEntry method so implementations can control if
the client should check for a more recent version in the cache

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

View raw message