You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by "Oleg Kalnichevski (JIRA)" <ji...@apache.org> on 2013/09/02 21:26:52 UTC

[jira] [Commented] (HTTPCLIENT-1395) Call the storage implementation only once on a cache miss

    [ https://issues.apache.org/jira/browse/HTTPCLIENT-1395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13756216#comment-13756216 ] 

Oleg Kalnichevski commented on HTTPCLIENT-1395:
-----------------------------------------------

Nikola

Please note that both BasicHttpCache class and HttpCache interface are package private, so they can be altered without breaking API compatibility. Instead of making CachingHttpClient dependent on BasicHttpCache you probably should change HttpCache instead.

Please also consider porting your patch to the latest SVN trunk. It is probably already too late for 4.2.x

Oleg 
                
> 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.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