[ 
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: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to