You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by "ASF subversion and git services (JIRA)" <ji...@apache.org> on 2018/01/02 11:48:00 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=16307923#comment-16307923 ] 

ASF subversion and git services commented on HTTPCLIENT-1395:
-------------------------------------------------------------

Commit c78032d638b19d0a44341e06561050401cc53aba in httpcomponents-client's branch refs/heads/master from [~olegk]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-client.git;h=c78032d ]

HTTPCLIENT-1395: added config parameter to skip an extra cache entry freshness check upon cache update in case of a cache miss


> 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
>            Assignee: Oleg Kalnichevski
>            Priority: Minor
>              Labels: stuck, volunteers-wanted
>             Fix For: 5.0 Beta1
>
>         Attachments: call-storage-implementation-once-4.2-branch.patch, call-storage-implementation-once-trunk.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 was sent by Atlassian JIRA
(v6.4.14#64029)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org