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
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
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:
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
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
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
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
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.
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
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
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
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:
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
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
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
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
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
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]
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
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
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
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.
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.
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
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
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
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.
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
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
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.
30 matches
Mail list logo
