Re: How To Change Page Store Size in DiskPageStore?

[Johan Compagner]

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.comhttp://nabble.com/
 .


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

Re: How To Change Page Store Size in DiskPageStore?

[Johan Compagner]

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.comhttp://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 

Re: How To Change Page Store Size in DiskPageStore?

[Chris Lintz]

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.comhttp://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]

Re: How To Change Page Store Size in DiskPageStore?

[Johan Compagner]

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.comhttp://nabble.com/
   .
  
  
   -
   To 

Re: How To Change Page Store Size in DiskPageStore?

[Chris Lintz]

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 

Re: How To Change Page Store Size in DiskPageStore?

[Brandon Harper]

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
 

Re: How To Change Page Store Size in DiskPageStore?

[Johan Compagner]

no it doesnt matter what id i generate or get. This is still not
enough because it doesnt say any thing if i can delete it or not. i
have an id 1 then i restart and i have id 2 can i then delete
everything from 1? No i cant because there could be live sessions from
1.

On 11/14/07, 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:

   
  
 
 

Re: How To Change Page Store Size in DiskPageStore?

[Chris Lintz]

There are still other ways around this.  If every process registered itself
via unique file in a known directory and a Page Store thread touched this
file every say 5 minutes, this gives more information to a thread to know
whether or not delete a Page Store directory associated with unique ID.   

For example,

MyWebSite-filestore/running_processes/uid1
MyWebSite-filestore/running_processes/uid2
MyWebSite-filestore/running_processes/uid2

Each Page store thread would then check the uid files that it did not
create.  For example, process 1 would check to see if uid1 and uid2 have
been touched in the last hour (just making up something way greater than 5
minutes).  If not, remove their associated PageStore files.

I will admit this is a bit more involved, but i am trying to present a
solution that doesn't require any configuration from a user perspective.




Johan Compagner wrote:
 
 no it doesnt matter what id i generate or get. This is still not
 enough because it doesnt say any thing if i can delete it or not. i
 have an id 1 then i restart and i have id 2 can i then delete
 everything from 1? No i cant because there could be live sessions from
 1.
 
 On 11/14/07, 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..
 
 

Re: How To Change Page Store Size in DiskPageStore?

[Johan Compagner]

i don't get this picture. What do you mean with a PageStore thread touches
this
file every 5 minutes? What does that bring us? Why can it suddenly remove
files?
Because yes the previous page store isn't there anymore, the server did
restart
so the file isn't being touched. and then what? Why can't it delete?

Again it a PageStore is not leading, yes it creates the files but it has no
way to know
if it can delete it, The only possible way i could think of if there was an
API in the servlet
spec for example on the context where i could ask for all the live session
ids.
That would be the only way to do it.

An unique file or unique id its still the same, there is nothing unique
about a pagestore
a page store from process B can or must be able to read files in from a
previous process B
that doesnt matter. There is no automatic way, it has to be configured for
deployment
wicket can't assume anything.

But still i am also not conviced that wicket needs to do this by a thread.
We just have to document
it then there must be a cleanup processs or scheduler if the server does
crash or is not terminated gracefully.
We could introduce such a thread in wicket if users really see the need for
it.

johan


On Nov 14, 2007 8:25 PM, Chris Lintz [EMAIL PROTECTED] wrote:


 There are still other ways around this.  If every process registered
 itself
 via unique file in a known directory and a Page Store thread touched this
 file every say 5 minutes, this gives more information to a thread to know
 whether or not delete a Page Store directory associated with unique ID.

 For example,

 MyWebSite-filestore/running_processes/uid1
 MyWebSite-filestore/running_processes/uid2
 MyWebSite-filestore/running_processes/uid2

 Each Page store thread would then check the uid files that it did not
 create.  For example, process 1 would check to see if uid1 and uid2 have
 been touched in the last hour (just making up something way greater than 5
 minutes).  If not, remove their associated PageStore files.

 I will admit this is a bit more involved, but i am trying to present a
 solution that doesn't require any configuration from a user perspective.




 Johan Compagner wrote:
 
  no it doesnt matter what id i generate or get. This is still not
  enough because it doesnt say any thing if i can delete it or not. i
  have an id 1 then i restart and i have id 2 can i then delete
  everything from 1? No i cant because there could be live sessions from
  1.
 
  On 11/14/07, 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.n1and
   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
  

Re: How To Change Page Store Size in DiskPageStore?

[Johan Compagner]

we discussed it and maybe there is a way by using the life cycle event of
the wicket servlet/filter..

When we get a clean shutdown we then just write a file to disk.
and the wicket load we read that file in and delete it again.

If there is no file it was a hard kill, and we can delete the pagestore
files.

Then i hope that the life cycle events works always when you shutdown the
complete container
or undeploy/redeploy the webapplication in a live system.

johan



On Nov 14, 2007 9:21 PM, Johan Compagner [EMAIL PROTECTED] wrote:

 i don't get this picture. What do you mean with a PageStore thread touches
 this
 file every 5 minutes? What does that bring us? Why can it suddenly remove
 files?
 Because yes the previous page store isn't there anymore, the server did
 restart
 so the file isn't being touched. and then what? Why can't it delete?

 Again it a PageStore is not leading, yes it creates the files but it has
 no way to know
 if it can delete it, The only possible way i could think of if there was
 an API in the servlet
 spec for example on the context where i could ask for all the live session
 ids.
 That would be the only way to do it.

 An unique file or unique id its still the same, there is nothing unique
 about a pagestore
 a page store from process B can or must be able to read files in from a
 previous process B
 that doesnt matter. There is no automatic way, it has to be configured for
 deployment
 wicket can't assume anything.

 But still i am also not conviced that wicket needs to do this by a thread.
 We just have to document
 it then there must be a cleanup processs or scheduler if the server does
 crash or is not terminated gracefully.
 We could introduce such a thread in wicket if users really see the need
 for it.

 johan


 On Nov 14, 2007 8:25 PM, Chris Lintz [EMAIL PROTECTED] wrote:

 
  There are still other ways around this.  If every process registered
  itself
  via unique file in a known directory and a Page Store thread touched
  this
  file every say 5 minutes, this gives more information to a thread to
  know
  whether or not delete a Page Store directory associated with unique ID.
 
  For example,
 
  MyWebSite-filestore/running_processes/uid1
  MyWebSite-filestore/running_processes/uid2
  MyWebSite-filestore/running_processes/uid2
 
  Each Page store thread would then check the uid files that it did not
  create.  For example, process 1 would check to see if uid1 and uid2 have
 
  been touched in the last hour (just making up something way greater than
  5
  minutes).  If not, remove their associated PageStore files.
 
  I will admit this is a bit more involved, but i am trying to present a
  solution that doesn't require any configuration from a user perspective.
 
 
 
 
  Johan Compagner wrote:
  
   no it doesnt matter what id i generate or get. This is still not
   enough because it doesnt say any thing if i can delete it or not. i
   have an id 1 then i restart and i have id 2 can i then delete
   everything from 1? No i cant because there could be live sessions from
   1.
  
   On 11/14/07, 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.n1and
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 

Re: How To Change Page Store Size in DiskPageStore?

[Johan Compagner]

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.comhttp://nabble.com/
 .


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

Re: How To Change Page Store Size in DiskPageStore?

[Johan Compagner]

But 50 is nothing (at least i think it is nothing) and linux should be able
to handle that just fine
Can somebody peak how many handles we take on those session files? Maybe we
leak somewhere
or do take more then we think.

johan



On Nov 8, 2007 2:04 AM, Matej Knopp [EMAIL PROTECTED] wrote:

 There is a constructor parameter in DiskPageStore constructor (the
 last int parameter) that says how many handles DiskPageStore will keep
 opened.

 But the default number of file handles is 50. If this is causing your
 server file handle problems than you should consider changing the
 configuration. Are you sure there are no other file handles leaking?
 What are the files opened?

 -Matej

 On 11/8/07, Brandon Harper [EMAIL PROTECTED] wrote:
  Hello All,
 
  Long story short, we're in the process of load testing an application
  built against Wicket 1.3 snapshot.  Unfortunately we've seen some
  server issues with sessions/page maps in the file store during
  testing, and I was wondering how I'd go about programatically changing
  the default page map size in DiskPageStore just to see if changing
  this value affects what we're seeing.
 
  FWIW, right now it looks like we're having issues under load with
  Wicket creating too many open file handles on a fairly default install
  of RHEL 5 which results in exceptions like this:
 
  java.lang.RuntimeException: java.io.FileNotFoundException:
  /usr/local/jboss-
 4.2.1.GA/server/website/work/jboss.web/localhost/_/Website-filestore/688F01368693E1A90ED61C8060A51A3E.n1/pm-nullhttp://4.2.1.ga/server/website/work/jboss.web/localhost/_/Website-filestore/688F01368693E1A90ED61C8060A51A3E.n1/pm-null
  (No such file or directory)
   at
  org.apache.wicket.protocol.http.pagestore.FileChannelPool.newFileChannel
 (FileChannelPool.java:104)
   at
  org.apache.wicket.protocol.http.pagestore.FileChannelPool.getFileChannel
 (FileChannelPool.java:171)
   at
 
 org.apache.wicket.protocol.http.pagestore.DiskPageStore$SessionEntry.savePage
 (DiskPageStore.java:224)
   at
 
 org.apache.wicket.protocol.http.pagestore.DiskPageStore.flushPagesToSaveList
 (DiskPageStore.java:788)
   at
 
 org.apache.wicket.protocol.http.pagestore.DiskPageStore$PageSavingThread.run
 (DiskPageStore.java:851)
   at java.lang.Thread.run(Thread.java:619)
  Caused by: java.io.FileNotFoundException:
  /usr/local/jboss-
 4.2.1.GA/server/me.dium.com/work/jboss.web/localhost/_/MediumWebsite-filestore/688F01368693E1A90ED61C8060A51A3E.n1/pm-nullhttp://4.2.1.ga/server/me.dium.com/work/jboss.web/localhost/_/MediumWebsite-filestore/688F01368693E1A90ED61C8060A51A3E.n1/pm-null
  (No such file or directory)
   at java.io.RandomAccessFile.open(Native Method)
   at java.io.RandomAccessFile.init(RandomAccessFile.java:212)
   at
  org.apache.wicket.protocol.http.pagestore.FileChannelPool.newFileChannel
 (FileChannelPool.java:99)
 
  Thanks,
 
  - Brandon
 
  --
  http://bharper.com
  http://devnulled.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]

Re: How To Change Page Store Size in DiskPageStore?

[Chris Lintz]

Guys I am on the same project so I can speak a bit more.  The real issue is
that on Redhat the default max directories is something like 32K.  We ran
out of file descriptors.  Basically for every unique session there is a
directory created for the second level cache. 

I think the real issue for us is that when a session expires the
corresponding second level cache is not removed from disk.  This seems like
a serious bug to me.  I have yet to see a second level cache be removed
unless a forced session invalidate() occurs. 

Any ideas on how we can get these page store files to be removed when a
session times out?   I have looked at tuning the DiskPageStore, but the
constuctor args dont appear as if they will help the issue:

DiskPageStore(java.io.File fileStoreFolder, int maxSizePerPagemap, int
maxSizePerSession, int fileChannelPoolCapacity) 



Johan Compagner wrote:
 
 But 50 is nothing (at least i think it is nothing) and linux should be
 able
 to handle that just fine
 Can somebody peak how many handles we take on those session files? Maybe
 we
 leak somewhere
 or do take more then we think.
 
 johan
 
 
 
 On Nov 8, 2007 2:04 AM, Matej Knopp [EMAIL PROTECTED] wrote:
 
 There is a constructor parameter in DiskPageStore constructor (the
 last int parameter) that says how many handles DiskPageStore will keep
 opened.

 But the default number of file handles is 50. If this is causing your
 server file handle problems than you should consider changing the
 configuration. Are you sure there are no other file handles leaking?
 What are the files opened?

 -Matej

 On 11/8/07, Brandon Harper [EMAIL PROTECTED] wrote:
  Hello All,
 
  Long story short, we're in the process of load testing an application
  built against Wicket 1.3 snapshot.  Unfortunately we've seen some
  server issues with sessions/page maps in the file store during
  testing, and I was wondering how I'd go about programatically changing
  the default page map size in DiskPageStore just to see if changing
  this value affects what we're seeing.
 
  FWIW, right now it looks like we're having issues under load with
  Wicket creating too many open file handles on a fairly default install
  of RHEL 5 which results in exceptions like this:
 
  java.lang.RuntimeException: java.io.FileNotFoundException:
  /usr/local/jboss-
 4.2.1.GA/server/website/work/jboss.web/localhost/_/Website-filestore/688F01368693E1A90ED61C8060A51A3E.n1/pm-nullhttp://4.2.1.ga/server/website/work/jboss.web/localhost/_/Website-filestore/688F01368693E1A90ED61C8060A51A3E.n1/pm-null
  (No such file or directory)
   at
 
 org.apache.wicket.protocol.http.pagestore.FileChannelPool.newFileChannel
 (FileChannelPool.java:104)
   at
 
 org.apache.wicket.protocol.http.pagestore.FileChannelPool.getFileChannel
 (FileChannelPool.java:171)
   at
 
 org.apache.wicket.protocol.http.pagestore.DiskPageStore$SessionEntry.savePage
 (DiskPageStore.java:224)
   at
 
 org.apache.wicket.protocol.http.pagestore.DiskPageStore.flushPagesToSaveList
 (DiskPageStore.java:788)
   at
 
 org.apache.wicket.protocol.http.pagestore.DiskPageStore$PageSavingThread.run
 (DiskPageStore.java:851)
   at java.lang.Thread.run(Thread.java:619)
  Caused by: java.io.FileNotFoundException:
  /usr/local/jboss-
 4.2.1.GA/server/me.dium.com/work/jboss.web/localhost/_/MediumWebsite-filestore/688F01368693E1A90ED61C8060A51A3E.n1/pm-nullhttp://4.2.1.ga/server/me.dium.com/work/jboss.web/localhost/_/MediumWebsite-filestore/688F01368693E1A90ED61C8060A51A3E.n1/pm-null
  (No such file or directory)
   at java.io.RandomAccessFile.open(Native Method)
   at java.io.RandomAccessFile.init(RandomAccessFile.java:212)
   at
 
 org.apache.wicket.protocol.http.pagestore.FileChannelPool.newFileChannel
 (FileChannelPool.java:99)
 
  Thanks,
 
  - Brandon
 
  --
  http://bharper.com
  http://devnulled.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#a13651858
Sent from the Wicket - User mailing list archive at Nabble.com.


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

Re: How To Change Page Store Size in DiskPageStore?

[Matej Knopp]

On Nov 8, 2007 6:43 PM, Eelco Hillenius [EMAIL PROTECTED] wrote:
  Guys I am on the same project so I can speak a bit more.  The real issue is
  that on Redhat the default max directories is something like 32K.  We ran
  out of file descriptors.  Basically for every unique session there is a
  directory created for the second level cache.

 But the file handles are pooled as far as I know? Matej, do we
 actually still need separate directories now that we use a page file?

Yeah, we do. We are using one file per pagemap. I believe that the
number of files can be limited as well as the number of directories.
So if you have one directory per session you'll have less entries than
one file per pagemap in one common directory.

-Matej


  I think the real issue for us is that when a session expires the
  corresponding second level cache is not removed from disk.  This seems like
  a serious bug to me.  I have yet to see a second level cache be removed
  unless a forced session invalidate() occurs.

 As far as I know, we do our best to delete those old sessions.
 AbstractHttpSessionStore puts a HttpSessionBindingListener in the
 user's http session when it starts so that the gets notified when
 DiskPageStore#unbind gets called by the second level cache session
 store and that should then take care of removing the files for that
 session.

 Can you debug why this isn't happening in your case?

 Eelco


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

Re: How To Change Page Store Size in DiskPageStore?

[Eelco Hillenius]

 Guys I am on the same project so I can speak a bit more.  The real issue is
 that on Redhat the default max directories is something like 32K.  We ran
 out of file descriptors.  Basically for every unique session there is a
 directory created for the second level cache.

But the file handles are pooled as far as I know? Matej, do we
actually still need separate directories now that we use a page file?

 I think the real issue for us is that when a session expires the
 corresponding second level cache is not removed from disk.  This seems like
 a serious bug to me.  I have yet to see a second level cache be removed
 unless a forced session invalidate() occurs.

As far as I know, we do our best to delete those old sessions.
AbstractHttpSessionStore puts a HttpSessionBindingListener in the
user's http session when it starts so that the gets notified when
DiskPageStore#unbind gets called by the second level cache session
store and that should then take care of removing the files for that
session.

Can you debug why this isn't happening in your case?

Eelco

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

Re: How To Change Page Store Size in DiskPageStore?

[Matej Knopp]

I see. That would be a serious bug indeed. Can you please file a high
priority JIRA issue? We'll look at it as soon as possible.

-Matej

On Nov 8, 2007 6:35 PM, Chris Lintz [EMAIL PROTECTED] wrote:

 Guys I am on the same project so I can speak a bit more.  The real issue is
 that on Redhat the default max directories is something like 32K.  We ran
 out of file descriptors.  Basically for every unique session there is a
 directory created for the second level cache.

 I think the real issue for us is that when a session expires the
 corresponding second level cache is not removed from disk.  This seems like
 a serious bug to me.  I have yet to see a second level cache be removed
 unless a forced session invalidate() occurs.

 Any ideas on how we can get these page store files to be removed when a
 session times out?   I have looked at tuning the DiskPageStore, but the
 constuctor args dont appear as if they will help the issue:

 DiskPageStore(java.io.File fileStoreFolder, int maxSizePerPagemap, int
 maxSizePerSession, int fileChannelPoolCapacity)




 Johan Compagner wrote:
 
  But 50 is nothing (at least i think it is nothing) and linux should be
  able
  to handle that just fine
  Can somebody peak how many handles we take on those session files? Maybe
  we
  leak somewhere
  or do take more then we think.
 
  johan
 
 
 
  On Nov 8, 2007 2:04 AM, Matej Knopp [EMAIL PROTECTED] wrote:
 
  There is a constructor parameter in DiskPageStore constructor (the
  last int parameter) that says how many handles DiskPageStore will keep
  opened.
 
  But the default number of file handles is 50. If this is causing your
  server file handle problems than you should consider changing the
  configuration. Are you sure there are no other file handles leaking?
  What are the files opened?
 
  -Matej
 
  On 11/8/07, Brandon Harper [EMAIL PROTECTED] wrote:
   Hello All,
  
   Long story short, we're in the process of load testing an application
   built against Wicket 1.3 snapshot.  Unfortunately we've seen some
   server issues with sessions/page maps in the file store during
   testing, and I was wondering how I'd go about programatically changing
   the default page map size in DiskPageStore just to see if changing
   this value affects what we're seeing.
  
   FWIW, right now it looks like we're having issues under load with
   Wicket creating too many open file handles on a fairly default install
   of RHEL 5 which results in exceptions like this:
  
   java.lang.RuntimeException: java.io.FileNotFoundException:
   /usr/local/jboss-
  4.2.1.GA/server/website/work/jboss.web/localhost/_/Website-filestore/688F01368693E1A90ED61C8060A51A3E.n1/pm-nullhttp://4.2.1.ga/server/website/work/jboss.web/localhost/_/Website-filestore/688F01368693E1A90ED61C8060A51A3E.n1/pm-null
   (No such file or directory)
at
  
  org.apache.wicket.protocol.http.pagestore.FileChannelPool.newFileChannel
  (FileChannelPool.java:104)
at
  
  org.apache.wicket.protocol.http.pagestore.FileChannelPool.getFileChannel
  (FileChannelPool.java:171)
at
  
  org.apache.wicket.protocol.http.pagestore.DiskPageStore$SessionEntry.savePage
  (DiskPageStore.java:224)
at
  
  org.apache.wicket.protocol.http.pagestore.DiskPageStore.flushPagesToSaveList
  (DiskPageStore.java:788)
at
  
  org.apache.wicket.protocol.http.pagestore.DiskPageStore$PageSavingThread.run
  (DiskPageStore.java:851)
at java.lang.Thread.run(Thread.java:619)
   Caused by: java.io.FileNotFoundException:
   /usr/local/jboss-
  4.2.1.GA/server/me.dium.com/work/jboss.web/localhost/_/MediumWebsite-filestore/688F01368693E1A90ED61C8060A51A3E.n1/pm-nullhttp://4.2.1.ga/server/me.dium.com/work/jboss.web/localhost/_/MediumWebsite-filestore/688F01368693E1A90ED61C8060A51A3E.n1/pm-null
   (No such file or directory)
at java.io.RandomAccessFile.open(Native Method)
at java.io.RandomAccessFile.init(RandomAccessFile.java:212)
at
  
  org.apache.wicket.protocol.http.pagestore.FileChannelPool.newFileChannel
  (FileChannelPool.java:99)
  
   Thanks,
  
   - Brandon
  
   --
   http://bharper.com
   http://devnulled.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#a13651858
 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 

Re: How To Change Page Store Size in DiskPageStore?

[Eelco Hillenius]

On Nov 8, 2007 3:31 PM, Chris Lintz [EMAIL PROTECTED] wrote:

 We get dangling cache files.  I have the sessions set to expire in 1 hour.  I
 check one of my servers and i see cache files from over a week old.  This
 could of only have occurred because of the multiple restarts.  Maybe its a
 bad timing where the HttpSessionBindingListener does not receive a
 notification.

We (Teachscape) had a couple of occasions where it seems we didn't get
notifications of expired sessions (using Jetty btw). So it may very
well be a bug. Unfortunately one that is hard to trace.

 I figured the DiskPageStore probably kept a map of cache files.  I those
 references were kept in memory, there be a separate thread that runs and
 grabs all file cache names in the file store (basically the JSESSIONIDs) and
 compare that to the references in the map to see what is a valid cache file.
 I suppose my assumptions are wrong.

The way to go then would be to work with a proper HttpSessionListener
and HttpSessionActivationListener. That should cover both expiries and
passivate/ activates.

Eelco

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

Re: How To Change Page Store Size in DiskPageStore?

[Martijn Dashorst]

No, as sometimes you actually want to resume those sessions.

I guess this is more  shell type of thing rather than somethign Wicket
can take care off. At least, as long as there is no bug in cleaning
the stuff up when sessions expire.

Martijn


On 11/9/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
 On Nov 8, 2007 3:09 PM, Johan Compagner [EMAIL PROTECTED] wrote:
  
  
   1)  Shall we file a Jira for a enhancement to the DiskPageStore which
   would
   be a cleanup of any dangling cache files not part of the current
   DiskPageStore instance?
 
 
  and which are dangling??
  How do you know that? If i stop tomcat (even in development mode)
  and i restart again nothing is dangling!! All the session are still there
  and are still
  using the page store.
 
  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?

 Eelco

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




-- 
Buy Wicket in Action: http://manning.com/dashorst
Apache Wicket 1.3.0-beta4 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta4/

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

Re: How To Change Page Store Size in DiskPageStore?

[Chris Lintz]

How can we limit the number of files and/or directories?  I only see the
option to limit the size of the session or the size of the pagemap for the
DiskPageStore ( DiskPageStore(java.io.File fileStoreFolder, int
maxSizePerPagemap, int maxSizePerSession, int fileChannelPoolCapacity) 



Matej Knopp-2 wrote:
 
 On Nov 8, 2007 6:43 PM, Eelco Hillenius [EMAIL PROTECTED] wrote:
  Guys I am on the same project so I can speak a bit more.  The real
 issue is
  that on Redhat the default max directories is something like 32K.  We
 ran
  out of file descriptors.  Basically for every unique session there is a
  directory created for the second level cache.

 But the file handles are pooled as far as I know? Matej, do we
 actually still need separate directories now that we use a page file?
 
 Yeah, we do. We are using one file per pagemap. I believe that the
 number of files can be limited as well as the number of directories.
 So if you have one directory per session you'll have less entries than
 one file per pagemap in one common directory.
 
 -Matej
 

  I think the real issue for us is that when a session expires the
  corresponding second level cache is not removed from disk.  This seems
 like
  a serious bug to me.  I have yet to see a second level cache be removed
  unless a forced session invalidate() occurs.

 As far as I know, we do our best to delete those old sessions.
 AbstractHttpSessionStore puts a HttpSessionBindingListener in the
 user's http session when it starts so that the gets notified when
 DiskPageStore#unbind gets called by the second level cache session
 store and that should then take care of removing the files for that
 session.

 Can you debug why this isn't happening in your case?

 Eelco


 -
 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#a13657063
Sent from the Wicket - User mailing list archive at Nabble.com.


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

Re: How To Change Page Store Size in DiskPageStore?

[Matej Knopp]

Yeah, something like this could be done, but then we would probably
have to user separate folder for each pagestore / application, just to
make sure that one page store doesn't touch other pagestore files.

Still, the question is whether we should do this at all. If you kill
your container (don't bring it down the regular way), shouldn't you be
also responsible for cleaning the temp folder?

-Matej

On Nov 9, 2007 12:31 AM, Chris Lintz [EMAIL PROTECTED] wrote:

 We get dangling cache files.  I have the sessions set to expire in 1 hour.  I
 check one of my servers and i see cache files from over a week old.  This
 could of only have occurred because of the multiple restarts.  Maybe its a
 bad timing where the HttpSessionBindingListener does not receive a
 notification.

 I figured the DiskPageStore probably kept a map of cache files.  I those
 references were kept in memory, there be a separate thread that runs and
 grabs all file cache names in the file store (basically the JSESSIONIDs) and
 compare that to the references in the map to see what is a valid cache file.
 I suppose my assumptions are wrong.




 Johan Compagner wrote:
 
 
 
  1)  Shall we file a Jira for a enhancement to the DiskPageStore which
  would
  be a cleanup of any dangling cache files not part of the current
  DiskPageStore instance?
 
 
  and which are dangling??
  How do you know that? If i stop tomcat (even in development mode)
  and i restart again nothing is dangling!! All the session are still there
  and are still
  using the page store.
 
  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..
 
  So as long as we can't do that, we can't delete files because we have no
  idea if the sessions are really gone or not.
  I guess a seperate cron job can clean up the files in that dir if they are
  really old?
 
  johan
 
 

 --
 View this message in context: 
 http://www.nabble.com/How-To-Change-Page-Store-Size-in-DiskPageStore--tf4768072.html#a13658369

 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]

Re: How To Change Page Store Size in DiskPageStore?

[Eelco Hillenius]

 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.

We could read the session timeout from web.xml and delete what is older.

Not a high priority thing for me tbh, but I think it can be done.

Eelco

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

Re: How To Change Page Store Size in DiskPageStore?

[Chris Lintz]

Ok here is a bit more clarity after digging further.  Timed out sessions do
trigger a removal of the of the PageStore file.  However if Tomcat is
restarted there is no cleanup of the PageStore files on disk.  In other
words the Page Store will leak those cache files and never clean them up.   
From these results, here are my questions now on all of this:

1)  Shall we file a Jira for a enhancement to the DiskPageStore which would
be a cleanup of any dangling cache files not part of the current
DiskPageStore instance? 

2)  I am stlll trying to figure out how to limit the max number of
directories and or files created by the DiskPageStore.  I am less concerned
about max sizes of sessions and page map and more concerned about the numer
of directories/files - any ideas?

thanks all for your quick responses and insight.



Matej Knopp-2 wrote:
 
 I see. That would be a serious bug indeed. Can you please file a high
 priority JIRA issue? We'll look at it as soon as possible.
 
 -Matej
 
 On Nov 8, 2007 6:35 PM, Chris Lintz [EMAIL PROTECTED] wrote:

 Guys I am on the same project so I can speak a bit more.  The real issue
 is
 that on Redhat the default max directories is something like 32K.  We ran
 out of file descriptors.  Basically for every unique session there is a
 directory created for the second level cache.

 I think the real issue for us is that when a session expires the
 corresponding second level cache is not removed from disk.  This seems
 like
 a serious bug to me.  I have yet to see a second level cache be removed
 unless a forced session invalidate() occurs.

 Any ideas on how we can get these page store files to be removed when a
 session times out?   I have looked at tuning the DiskPageStore, but the
 constuctor args dont appear as if they will help the issue:

 DiskPageStore(java.io.File fileStoreFolder, int maxSizePerPagemap, int
 maxSizePerSession, int fileChannelPoolCapacity)




 Johan Compagner wrote:
 
  But 50 is nothing (at least i think it is nothing) and linux should be
  able
  to handle that just fine
  Can somebody peak how many handles we take on those session files?
 Maybe
  we
  leak somewhere
  or do take more then we think.
 
  johan
 
 
 
  On Nov 8, 2007 2:04 AM, Matej Knopp [EMAIL PROTECTED] wrote:
 
  There is a constructor parameter in DiskPageStore constructor (the
  last int parameter) that says how many handles DiskPageStore will keep
  opened.
 
  But the default number of file handles is 50. If this is causing your
  server file handle problems than you should consider changing the
  configuration. Are you sure there are no other file handles leaking?
  What are the files opened?
 
  -Matej
 
  On 11/8/07, Brandon Harper [EMAIL PROTECTED] wrote:
   Hello All,
  
   Long story short, we're in the process of load testing an
 application
   built against Wicket 1.3 snapshot.  Unfortunately we've seen some
   server issues with sessions/page maps in the file store during
   testing, and I was wondering how I'd go about programatically
 changing
   the default page map size in DiskPageStore just to see if changing
   this value affects what we're seeing.
  
   FWIW, right now it looks like we're having issues under load with
   Wicket creating too many open file handles on a fairly default
 install
   of RHEL 5 which results in exceptions like this:
  
   java.lang.RuntimeException: java.io.FileNotFoundException:
   /usr/local/jboss-
 
 4.2.1.GA/server/website/work/jboss.web/localhost/_/Website-filestore/688F01368693E1A90ED61C8060A51A3E.n1/pm-nullhttp://4.2.1.ga/server/website/work/jboss.web/localhost/_/Website-filestore/688F01368693E1A90ED61C8060A51A3E.n1/pm-null
   (No such file or directory)
at
  
 
 org.apache.wicket.protocol.http.pagestore.FileChannelPool.newFileChannel
  (FileChannelPool.java:104)
at
  
 
 org.apache.wicket.protocol.http.pagestore.FileChannelPool.getFileChannel
  (FileChannelPool.java:171)
at
  
 
 org.apache.wicket.protocol.http.pagestore.DiskPageStore$SessionEntry.savePage
  (DiskPageStore.java:224)
at
  
 
 org.apache.wicket.protocol.http.pagestore.DiskPageStore.flushPagesToSaveList
  (DiskPageStore.java:788)
at
  
 
 org.apache.wicket.protocol.http.pagestore.DiskPageStore$PageSavingThread.run
  (DiskPageStore.java:851)
at java.lang.Thread.run(Thread.java:619)
   Caused by: java.io.FileNotFoundException:
   /usr/local/jboss-
 
 4.2.1.GA/server/me.dium.com/work/jboss.web/localhost/_/MediumWebsite-filestore/688F01368693E1A90ED61C8060A51A3E.n1/pm-nullhttp://4.2.1.ga/server/me.dium.com/work/jboss.web/localhost/_/MediumWebsite-filestore/688F01368693E1A90ED61C8060A51A3E.n1/pm-null
   (No such file or directory)
at java.io.RandomAccessFile.open(Native Method)
at
 java.io.RandomAccessFile.init(RandomAccessFile.java:212)
at
  
 
 org.apache.wicket.protocol.http.pagestore.FileChannelPool.newFileChannel
  (FileChannelPool.java:99)
  
   Thanks,
  

Re: How To Change Page Store Size in DiskPageStore?

[Eelco Hillenius]

 Ok here is a bit more clarity after digging further.  Timed out sessions do
 trigger a removal of the of the PageStore file.  However if Tomcat is
 restarted there is no cleanup of the PageStore files on disk.  In other
 words the Page Store will leak those cache files and never clean them up.
 From these results, here are my questions now on all of this:

 1)  Shall we file a Jira for a enhancement to the DiskPageStore which would
 be a cleanup of any dangling cache files not part of the current
 DiskPageStore instance?

Sure.

 2)  I am stlll trying to figure out how to limit the max number of
 directories and or files created by the DiskPageStore.  I am less concerned
 about max sizes of sessions and page map and more concerned about the numer
 of directories/files - any ideas?

Well, think about the implication of that limit: you basically limit
the number of concurrent sessions you can handle. Your servlet
container/ load balancer would be a better place to impose things like
that.

Do you really have a limit on how many files can be created? You
typically want to limit the number of active file handles at any given
time, and I think that is already part of the package. To limit the
number of files/ directories strikes me as on odd thing to want.

Eelco

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

Re: How To Change Page Store Size in DiskPageStore?

[Johan Compagner]

 1)  Shall we file a Jira for a enhancement to the DiskPageStore which
 would
 be a cleanup of any dangling cache files not part of the current
 DiskPageStore instance?


and which are dangling??
How do you know that? If i stop tomcat (even in development mode)
and i restart again nothing is dangling!! All the session are still there
and are still
using the page store.

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

So as long as we can't do that, we can't delete files because we have no
idea if the sessions are really gone or not.
I guess a seperate cron job can clean up the files in that dir if they are
really old?

johan

Re: How To Change Page Store Size in DiskPageStore?

[Eelco Hillenius]

On Nov 8, 2007 3:09 PM, Johan Compagner [EMAIL PROTECTED] wrote:
 
 
  1)  Shall we file a Jira for a enhancement to the DiskPageStore which
  would
  be a cleanup of any dangling cache files not part of the current
  DiskPageStore instance?


 and which are dangling??
 How do you know that? If i stop tomcat (even in development mode)
 and i restart again nothing is dangling!! All the session are still there
 and are still
 using the page store.

 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?

Eelco

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

Re: How To Change Page Store Size in DiskPageStore?

[Johan Compagner]

  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

Re: How To Change Page Store Size in DiskPageStore?

[Matej Knopp]

 We could read the session timeout from web.xml and delete what is older.

But should we really do that? When session timeouts, the data is
deleted anyway. These dangling files seem to be a caused by
something else.

-Matej


 Not a high priority thing for me tbh, but I think it can be done.


 Eelco

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

Re: How To Change Page Store Size in DiskPageStore?

[Eelco Hillenius]

On Nov 8, 2007 3:29 PM, Matej Knopp [EMAIL PROTECTED] wrote:
  We could read the session timeout from web.xml and delete what is older.

 But should we really do that? When session timeouts, the data is
 deleted anyway. These dangling files seem to be a caused by
 something else.

If the sessions are picked up again after a restart, I agree we
wouldn't need that.

Eelco

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

Re: How To Change Page Store Size in DiskPageStore?

[Johan Compagner]

except if you hard kill the servlet container or if the container crashes..

Then with a restart everything is completely new and all the old onces will
stick for ever..

johan



On Nov 9, 2007 12:32 AM, Eelco Hillenius [EMAIL PROTECTED] wrote:

 On Nov 8, 2007 3:29 PM, Matej Knopp [EMAIL PROTECTED] wrote:
   We could read the session timeout from web.xml and delete what is
 older.
 
  But should we really do that? When session timeouts, the data is
  deleted anyway. These dangling files seem to be a caused by
  something else.

 If the sessions are picked up again after a restart, I agree we
 wouldn't need that.

 Eelco

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

Re: How To Change Page Store Size in DiskPageStore?

[Matej Knopp]

There is a constructor parameter in DiskPageStore constructor (the
last int parameter) that says how many handles DiskPageStore will keep
opened.

But the default number of file handles is 50. If this is causing your
server file handle problems than you should consider changing the
configuration. Are you sure there are no other file handles leaking?
What are the files opened?

-Matej

On 11/8/07, Brandon Harper [EMAIL PROTECTED] wrote:
 Hello All,

 Long story short, we're in the process of load testing an application
 built against Wicket 1.3 snapshot.  Unfortunately we've seen some
 server issues with sessions/page maps in the file store during
 testing, and I was wondering how I'd go about programatically changing
 the default page map size in DiskPageStore just to see if changing
 this value affects what we're seeing.

 FWIW, right now it looks like we're having issues under load with
 Wicket creating too many open file handles on a fairly default install
 of RHEL 5 which results in exceptions like this:

 java.lang.RuntimeException: java.io.FileNotFoundException:
 /usr/local/jboss-4.2.1.GA/server/website/work/jboss.web/localhost/_/Website-filestore/688F01368693E1A90ED61C8060A51A3E.n1/pm-null
 (No such file or directory)
  at
 org.apache.wicket.protocol.http.pagestore.FileChannelPool.newFileChannel(FileChannelPool.java:104)
  at
 org.apache.wicket.protocol.http.pagestore.FileChannelPool.getFileChannel(FileChannelPool.java:171)
  at
 org.apache.wicket.protocol.http.pagestore.DiskPageStore$SessionEntry.savePage(DiskPageStore.java:224)
  at
 org.apache.wicket.protocol.http.pagestore.DiskPageStore.flushPagesToSaveList(DiskPageStore.java:788)
  at
 org.apache.wicket.protocol.http.pagestore.DiskPageStore$PageSavingThread.run(DiskPageStore.java:851)
  at java.lang.Thread.run(Thread.java:619)
 Caused by: java.io.FileNotFoundException:
 /usr/local/jboss-4.2.1.GA/server/me.dium.com/work/jboss.web/localhost/_/MediumWebsite-filestore/688F01368693E1A90ED61C8060A51A3E.n1/pm-null
 (No such file or directory)
  at java.io.RandomAccessFile.open(Native Method)
  at java.io.RandomAccessFile.init(RandomAccessFile.java:212)
  at
 org.apache.wicket.protocol.http.pagestore.FileChannelPool.newFileChannel(FileChannelPool.java:99)

 Thanks,

 - Brandon

 --
 http://bharper.com
 http://devnulled.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]