hc-dev mailing list archives

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

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

Jon Moore commented on HTTPCLIENT-1347:
---------------------------------------

I also need to refresh my memory here, which I'm about to attempt to do. However, in the debugger
output Joe posted earlier, you can see that both entries share a "Resource" (the response
body) object, so that's actually just been stored once. I need to remember how that works,
though, as it might mean you need to implement something additional (a ResourceFactory) for
a new backend--headers and bodies are stored separately.

At the very least I think we have all clearly demonstrated we need much better documentation
about how to build new storage backends!

Let me see what I can figure out.

> 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