[icedtea-web] RFC: Fix caching of compressed content

[Andrew Azores]

On 05/02/2014 07:27 PM, Omair Majid wrote:
> Hi,
>
> * Andrew Azores <aazores at redhat.com> [2014-05-02 16:58]:
>> On 05/02/2014 04:32 PM, Omair Majid wrote:
>>> It was brought to my attention that icedtea-web was re-downloading the
>>> jars (which should have been cached) on subsequent runs of a jnlp
>>> application. I dug into it and found a real bug.
>>>
>>> To decide if an item is cached, icedtea-web does a HEAD request and
>>> compares the Content-Length with the size of the file. This works fine
>>> when the jars were not compressed. When the jars are fetched compressed
>>> and then uncompressed on disk, there is a mismatch between the sizes and
>>> icedtea-web decides the content is not cached.
>>>
>>> The attached patch stores the compressed size in the cache info file and
>>> uses that instead of the actual file size in the size-comparison.
>> Can there be a reproducer for this?
> This is not a functional change (at least, I really hope it isn't). It's
> a performance change. I am not sure how to write a reproducer that
> checks for startup speed. Any suggestions?

This seems to actually have fixed redownloading of at least some test 
cases, actually. I don't know a good way to write a reproducer for 
startup speed either, but the fixed caching should be testable. I didn't 
realize this was just a happy side effect of this patch :)

>
>> Or is there already an existing one?
> The test case that I used for this is a production server that's
> internal, sadly.
>
>> Manually testing looks good though, nothing appears broken and
>> applets (eg Elluminate) don't appear to be redownloading, according
>> to the progress bar which just jumps from 0 to 100.
> Yeah, that 0 to 100 jump means that the cache is working correctly. Were
> any of these test cases re-downloading before?

Elluminate is the test case I noticed the caching difference with - 
other test cases generally load quickly enough that I suppose it wasn't 
as apparent. Elluminate takes long enough to download that now that I've 
tested it again, the lack of caching with it is definitely noticeable.

>
>> The delay before
>> this happens is just the overhead from establishing a connection and
>> waiting for the result of the HEAD request(s), right?
> Yes. This delay should be very small (I measured 0 seconds on many
> lookups) but can be as large as ~10 seconds. See my other patch for a
> timeout implementation that improves this too.
>
> Thanks,
> Omair
>

Thanks,

-- 
Andrew A