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