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

[Omair Majid]

On 03/21/2011 03:49 PM, Andrew Su wrote:
>> On 03/21/2011 03:21 PM, Andrew Su wrote:
>>>> On 03/21/2011 02:49 PM, Andrew Su wrote:
>>>>>> 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 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.
>
> The blob I wrote from previous response is talking about the issue
> with implementation of removing old files and keeping new ones.
> (Refering to problem that we don't know if the file is in use.)
>

Yes, but keeping old files around as a fix seems like the wrong 
solution. If we are going to add a size-limited cache, then it should 
behave like a cache. If there are technical issues, lets address them.

>>
>>> 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.
>
> This is relevant since we're talking about wanting to remove old file
> and keeping new ones. We can not remove old files because we don't
> know if they are in use. The way I see to fix this is to do it on the
> -last- jvm shutdown for plugin/javaws. Where it will have to find out
> which file is new and save those by going through all the files. I'm
> just not happy about having to go through every file.
>

You said earlier: "I'm not saying this doesn't happen with the way I'm 
implementing it. Similar situation can happen." And I agree: if a jar is 
updated while you are running an applet that uses it, it will get 
overwritten. Whether you have both old and new jars in perm, or both old 
and new jars in temp - the result is the same. From what I can tell, the 
only case where the result will be different is when the old jar is in 
perm and the new in temp (how likely this is, I dont know). The result 
will also be the same in the current implementation.

So I dont see how a problem that exists in current code, exists in your 
patch and in a suggested improvement is an argument on why the suggested 
improvement isnt a good idea.

Cheers,
Omair