[rfc][icedtea-web] clean Cache

[Jie Kang]

Hello,


The change to last modified being >= 0 makes it so any-time there are resources sent with no last-modified header, we do not re-download unless FORCE policy is set. However there is no way for us to set the FORCE policy outside of compile-time and there is no option for the user to re-download without clearing cache. In this situation, it is much more sensible for us to just always re-download. Until we get a viable alternative to last-modified for figuring out when to cache things, re-downloading any-time we don't see the last modified is the option to go for.

The change to cache deletion looks okay to me.


Regards,

----- Original Message -----
> Hello,
> 
>     While looking for a fix for PR906
>     http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=906 , which is a
>     bug that redownloads jars if there is no Last-Modified Http Header
>     accompanying them, it was found that the cache would
> not be cleaned properly. This was occurring due to the names being the same
> and would check first whether it should keep it, which led to keeping the
> old cache entries that were marked 'delete=true' in their respective .info
> files. By changing the order of checking whether to delete first then to
> keep, fixes the problem. A good way to test this is to javaws
> http://files.gokgs.com/javaBin/cgoban.jnlp with and without the patch to
> see.
> 
>     */netx/net/sourceforge/jnlp/cache/CacheUtil.java:
>     Changed position of keep and delete, so clean cache first checks
>     whether something is to be deleted then to whether to keep
> 
> I was also wondering if someone had an idea on how we should handle the case
> of updating jars when no last-modified http header is provided. At the
> moment it re-downloads the jars even though it doesn't really need to. I
> have attached a patch (noLastModified.patch) that works by when checking if
> the file isCurrent with no last-modified http header is provided as true
> resulting in not needing to re-download the jars. Another way I was thinking
> about fixing this is that if you are not re-downloading the jnlp as is the
> case on http://files.gokgs.com/javaBin/cgoban.jnlp then the jars don't need
> to be updated. Any thoughts ?
> 
> Thank you,
> Lukasz Dracz
> 
> 

-- 

Jie Kang