I assume Wicket could just create it's own persistent ID on startup
which it uses to name the dir.   Any other parent dirs which don't
match that ID get deleted on startup?

On Nov 14, 2007 11:05 AM, Chris Lintz <[EMAIL PROTECTED]> wrote:
>
> The process ID is just an idea for a unique ID.  If that wont work for you,
> lets dream another unique ID .
>
>
>
>
> Johan Compagner wrote:
> >
> > ohh wait that also doesn't work (process id can also be generated once
> > ofcourse) but you can have mulitply dirs created with 10 different
> > processes that are all valid. so that doesn't solve anything
> >
> > On 11/14/07, Johan Compagner <[EMAIL PROTECTED]> wrote:
> >> can you get the current process id by general api in java? have to
> >> look at Runtime then.
> >>
> >> On 11/14/07, Chris Lintz <[EMAIL PROTECTED]> wrote:
> >> >
> >> > That makes sense.  Another thought that possibly makes it a bit easier
> >> is
> >> to
> >> > name the page store directories with a unique process identifier. For
> >> > example, if my session ID is B31598D4B206B75161AFE08FB5610D54.n1 and
> >> the
> >> > process ID is 123456, then the Page store directory would be:
> >> >
> >> >    MyWebSite-filestore/123456/B31598D4B206B75161AFE08FB5610D54.n1
> >> >
> >> > With a structure like that it would be easy for a thread to remove the
> >> Page
> >> > store directories that do not have the current process ID.
> >> >
> >> > Just a thought.
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > Johan Compagner wrote:
> >> > >
> >> > > 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]
> >> > >>
> >> > >>
> >> > >
> >> > >
> >> >
> >> > --
> >> > View this message in context:
> >> >
> >> http://www.nabble.com/How-To-Change-Page-Store-Size-in-DiskPageStore--tf4768072.html#a13751284
> >> > Sent from the Wicket - User mailing list archive at Nabble.com.
> >> >
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> > For additional commands, e-mail: [EMAIL PROTECTED]
> >> >
> >> >
> >>
> >
> > ---------------------------------------------------------------------
> > 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#a13753054
>
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>



-- 
http://bharper.com
http://devnulled.com

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to