hc-dev mailing list archives

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

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

Joe Campbell commented on HTTPCLIENT-1347:
------------------------------------------

Ok - Lemme just walk through the code with this so that we are both clear (and to make sure
I am not saying anything that doesn't match with the code currently) - You have an implementation
of a BasicHttpCache and you have implemented your own storage back end. The BasicHttpCache
does the following: 

storeInCache(HttpHost target, HttpRequest request, HttpCacheEntry entry)

which checks to see if the entry to be stored is a variant entry. If the entry is a variant
it calls storeVariantEntry(target, request, entry). 

StoreVariantEntry calls storage.putEntry(variantURI, entry) and then creates the HttpCacheUpdateCallback
used by the updateEntry call which is then made by calling storage.updateEntry(parentURI,
callback).

So using the logging from your server/example:

getting entry: http://localhost:8000/1
getting entry: http://localhost:8000/1
getting entry: http://localhost:8000/1

Next PUT THE VARIANT (<--- I added this line)

putting entry: {Accept-Encoding=gzip}http://localhost:8000/1
{{Accept-Encoding=gzip}http://localhost:8000/1=[request date=Mon Jan 13 19:12:39 EST 2014;
response date=Mon Jan 13 19:12:39 EST 2014; statusLine=HTTP/1.1 200 OK]}

THEN go update its parent (<--- I added this line)

updating entry: http://localhost:8000/1
getting entry: http://localhost:8000/1
putting entry: http://localhost:8000/1

Now the interaction for Item #1 is DONE and there are two entries, a parent one and the variant
one for GZIP encoding - which is correct as far as the cache is concerned.

So I think we agree with the above (correct me if I am wrong). Assuming we agree up to this
point, I think the documentation for updateEntry may need to be revised/clarified a little.
updateEntry is going to atomically update an entry by using the call back that in turn creates
the 'updated' entry that is going to be stored, which can then be put back into the cache
with a "storage.put()" call all in one fell swoop.  It might feel a little odd, but the callback
in this case is the creator of an atomic PUT ITEM even if the thing at the put location starts
out NULL. The call back is the atomicity. Hence the documentation that says this should be
an atomic replacement of an item (which it is).

Does that make sense?

I do wanna look a little deeper with Jon tomorrow because this also looks like it is also
using the variant BODY as the resource in the put (which I think MAY be wrong - but I have
to do a little more digging to prove that).

> 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