hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Patacchiola (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HTTPCLIENT-1347) gzip responses doubly cached
Date Tue, 14 Jan 2014 02:17:54 GMT

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

Adam Patacchiola commented on HTTPCLIENT-1347:
----------------------------------------------

Joe, I cut and pasted the variant key from the test client log output - gzip is not specified;
I was trying to say the http client must be passing the wrong key to the http storage putEntry.


I think the problem lies in your assumption that the resource is only being stored once. If
i'm implementing a disk cache, (which I am here: https://github.com/surespot/android-async-http/blob/master/src/com/twofours/surespot/SurespotCachingHttpClient.java#L112)
when updateEntry is called I am saving the resource body again for the (in this case 'root'
url). So the resource body is saved both for the variant url (which is never used as a key
for a get) and the "root" url (which is added to the cache by the questionable update-non-existant-key
updateEntry call). I guess if you don't care about cache storage efficiency this doesn't matter
(I am using this on a mobile device so happen to care a lot), but why store keys in the cache
that are never going to be hit? If it always used the variant url key, or always used the
root url key that would make a lot more sense. 

The test client is only ever getting gzipped responses, why would there be two cache entries?










> gzip responses doubly cached
> ----------------------------
>
>                 Key: HTTPCLIENT-1347
>                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1347
>             Project: HttpComponents HttpClient
>          Issue Type: Bug
>          Components: HttpCache
>    Affects Versions: 4.2.5
>         Environment: ARCH Linux kernel 3.8.8-1
> node.js 0.8.22
>            Reporter: Adam Patacchiola
>             Fix For: 4.4 Final
>
>         Attachments: Screen Shot 2014-01-11 at 7.11.36 PM.png, Screen Shot 2014-01-13
at 3.56.19 PM.png, Showing_entry_pointer.png, httpClientCacheTest.tar.gz, httpClientTestServer.js
>
>
> Compressed responses are cached twice. 
> Run the attached server (node.js 0.8.22) and client tests. Create an "assets" directory
under where you are running the server and add two files named 1 and 2 ( < 1000000 bytes)
. You will see that after the test is run the cache dump output displays 2 sets of entries
for each request, each containing the full content length of the file.
> Changing the implementation of HttpCacheStorage updateEntry to not update non existent
entries (as I believe the correct implementation should do) throws exceptions. 



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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


Mime
View raw message