[RFC][Icedtea-Web]: Enforce cache limit based on deployment.properties

Omair Majid omajid at redhat.com
Mon Mar 21 12:35:35 PDT 2011


On 03/21/2011 03:21 PM, Andrew Su wrote:
>
>
> ----- Original Message -----
>> On 03/21/2011 02:49 PM, Andrew Su wrote:
>>>
>>>
>>> ----- Original Message -----
>>>> On 03/20/2011 09:03 PM, Andrew Su wrote:
>>>>> Hello,
>>>>>
>>>>> I have attached a patch which will properly drop the
>>>>> downloaded files into the appropriate directory (temp and
>>>>> perm) inside the cache folder. Where temp will be deleted
>>>>> upon jvm shutdown if no other instances of plugin or javaws
>>>>> is running.
>>>>>
>>>>> I have did some testing with some applets and all seems to
>>>>> work. Another patch for updating itw-settings's cache control
>>>>> should be soon since it currently doesn't check for running
>>>>> instances before allowing for deleting cache (also need to be
>>>>> modified to work with new directory structure).
>>>>>
>>>>> Any comments questions or concerns?
>>>>>
>>>>
>>>> I havent looked at the patch in detail, but I am wondering
>>>> what happens when the (perm) cache is full? What cache
>>>> replacement policy does it follow?
>>
>>
>>> When the cache is full it will place any files to be downloaded
>>> into the temp cache folder. In the event that the file already
>>> exist in the perm cache, if the file we are to use is newer, it
>>> will check if overwriting the old file will still put us within
>>> the limit set, if so proceed (This is how we're doing it right
>>> now minus the check for size). If it will go over the limit, file
>>> will be placed in temp. When trying to access a file, it first
>>> checks temp first as temp should in all cases contain the most
>>> updated version of the file.
>>>
>>
>> That seems a very, um, strange. So we have a file cache that's not
>> really a cache? Even if the user never again uses files from the
>> cache, they still stick around?
>>
>> I agree that the behviour right now isnt perfect, but this patch
>> seems like a particularly weird way to fix it.
>
> I think I understand what you are saying.. If the file is old and it
> doesn't fit, old file stays and we only use new file but old file is
> not deleted?
>

Exactly. If we are implementing a cache, it needs to behave like a 
cache. In particular, keeping old files around and deleting newer files 
doesn't seem like such a great idea.

> I considered removing the old file, but that comes with it's own
> minor issue. Let's say I go to a webpage and it loads an applet,
> while I'm using this applet the owner of the applet decided to update
> it. Then when I open another instance of this webpage that runs the
> applet, it overwrites the jar and I lose what I had running before.
> I'm not saying this doesn't happen with the way I'm implementing it.
> Similar situation can happen.

Isnt this an issue currently too? Updating something while it's running 
is a problem, but I fail to see how it's relevant to this discussion.

>
> TBH, I wouldn't even want overwrite any files while plugin/javaws is
> running.
>

Exactly. We know that JVM can behave in all sorts of weird ways if jars 
that it's using are modified.

Cheers,
Omair



More information about the distro-pkg-dev mailing list