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

[Andrew Su]

----- Original Message -----
> 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.

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.)

> 
> > 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.

> 
> >
> > 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.

Yup.

Regards,
  Andrew