Yes the pagestore knows which files it makes, but it is not the controller
of those files
because the only thing that controls if the file must be deleted or not is
the servlet container
with the session objects.

and as far as i know there is no api where i can ask which sessions are
still active.
So the only thing we could do is have a thread running that is waking up
every day once
and checks if there are files older then X. And that thread must be
configured by you
explicitly setting the timeout that you want to have.

johan




On Nov 14, 2007 12:04 AM, Chris Lintz <[EMAIL PROTECTED]> wrote:

>
> I think from previous threads there was discussion about something that
> you
> could do.  For instance, the Page store should know what cache files it is
> controlling.  By that logic alone it can deduce what it is no longer
> referencing and cleanup what was left form it.
>
> It seems silly to me to ask people to rely on graceful restarts or write
> your own cleanup script from a framework that created cache files.  It
> seems
> fairly standard to ask "clean up what was yours."   I'd like to hear other
> input from average users.
>
>
>
> Johan Compagner wrote:
> >
> > as long as your server doesn't crash and isn't terminate by a kill -9
> > no files are leaked..
> >
> > When that does happen then yes you have to clean it up.
> > If you dont care about those files after a restart then in the script
> that
> > starts your webcontainer
> > you will just remove all the files in the work dir.
> >
> > I don't think wicket can do much about it.
> >
> > johan
> >
> >
> > On Nov 13, 2007 10:41 PM, Chris Lintz <[EMAIL PROTECTED]>
> > wrote:
> >
> >>
> >> All,
> >> I have submitted a Jira on this topic.  I will leave it to the great
> >> minds
> >> to debate.  In any case, it appears restarting the container cannot
> >> notify
> >> the HttpSessionListeners that are bound to the page store files.  It
> >> would
> >> be nice if the framework can cleanup what I consider a leak of the
> cache
> >> files it created.  Otherwise folks like myself living in an high
> traffic
> >> site are forced to generate script look for old page store cache files.
> >>
> >> https://issues.apache.org/jira/browse/WICKET-1158
> >>
> >>
> >> Johan Compagner wrote:
> >> >
> >> >>
> >> >> > And from top of my head there is no api to get all the current
> >> session
> >> >> id's
> >> >> > from
> >> >> > an instance when the instance does start up..
> >> >>
> >> >> But we could ditch ALL the directories it can find in the temp
> >> >> directory the page store uses when starting up, right?
> >> >>
> >> >
> >> > No we can't do that, If you as you should terminate your web
> container
> >> > gracefully
> >> > then the web container will save all the sessions to disk. Then if
> you
> >> > restart it again
> >> > all the sessions are loaded again. And yes the application works just
> >> as
> >> > it was never
> >> > restarted. But if we throw away all the page stores. Then we loose
> all
> >> the
> >> > data
> >> > of sessions that are currently active.
> >> >
> >> > The only thing i can think of is having some check that only deletes
> >> > things
> >> > that are not touched for X hours or days.
> >> >
> >> > johan
> >> >
> >> >
> >>
> >> --
> >> View this message in context:
> >>
> http://www.nabble.com/How-To-Change-Page-Store-Size-in-DiskPageStore--tf4768072.html#a13735298
> >> Sent from the Wicket - User mailing list archive at
> >> Nabble.com <http://nabble.com/><http://nabble.com/>
> >> .
> >>
> >>
> >> ---------------------------------------------------------------------
> >>  To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >>
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/How-To-Change-Page-Store-Size-in-DiskPageStore--tf4768072.html#a13736689
>  Sent from the Wicket - User mailing list archive at 
> Nabble.com<http://nabble.com/>
> .
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Reply via email to