Thanks for the hints. Between those and what we've already known, we should
be fine...
Bob.
Johan Compagner wrote:
Tomcat can do that:
http://tomcat.apache.org/tomcat-5.5-doc/config/context.html
see anti resource and anti jar locking.
I think the end result will be that tomcat
can't you run in deployment mode instead of development mode?
then that shouldn't happen.
I can see if we can backport it.
johan
On 2/1/07, beboris [EMAIL PROTECTED] wrote:
We have found a pretty weird situation with too many open files error on
our alpha-testing site. Further analysis
We will, when we are on production. Now that we are are still in alpha we
prefer development (hey, we wrote our first line of wicket code 5-6 weeks
ago!)
Also, even in deployment mode 'lsof' still shows us a lot of open files (one
per resource) if we don't unpack resources from the .jar . It may
one per resource will i think not really change.
johan
On 2/1/07, beboris [EMAIL PROTECTED] wrote:
We will, when we are on production. Now that we are are still in alpha we
prefer development (hey, we wrote our first line of wicket code 5-6
weeks
ago!)
Also, even in deployment mode 'lsof'
Wasn't it optimized now so that it only hits jars once and only hits
per resource where normal files are involved?
Eelco
On 2/1/07, Johan Compagner [EMAIL PROTECTED] wrote:
one per resource will i think not really change.
johan
On 2/1/07, beboris [EMAIL PROTECTED] wrote:
We will,
yes the modification checker.
But we do need to really load the resource out of the jar file once. So that
file handle will be used.
johan
On 2/1/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
Wasn't it optimized now so that it only hits jars once and only hits
per resource where normal files
Yeah, but that would be always one fd for a jar, no matter how many
files in it that have to be read, right?
Eelco
On 2/1/07, Johan Compagner [EMAIL PROTECTED] wrote:
yes the modification checker.
But we do need to really load the resource out of the jar file once. So that
file handle will
that is what you would think... But why generates a modification check one
file handle for every check in the file?
because UrlConnection.connect() has again a JarUrlConnection internally that
makes a new connection to that jar file
and UrlConnection does have a connect() but not a disconnect()
Would it be possible and useful to cache the URL connection? Does it
have a time out and/ or does it use an exclusive lock?
Eelco
On 2/1/07, Johan Compagner [EMAIL PROTECTED] wrote:
that is what you would think... But why generates a modification check one
file handle for every check in the
why would you cache? and which one? the url connection to an entry in a jar
file (thats the JarUrlConnection)
or (i guess) the FileUrlConnection (to the jar file itself)
both don't make much sense to cache
the first one we don't need to cache we only need to use it once by really
loading the
Too bad,
Eelco
On 2/1/07, Johan Compagner [EMAIL PROTECTED] wrote:
why would you cache? and which one? the url connection to an entry in a jar
file (thats the JarUrlConnection)
or (i guess) the FileUrlConnection (to the jar file itself)
both don't make much sense to cache
the first one
It's hard for me to say, what the right way to fix this situation is. The
number of open files (that look to the OS as wicket .jar files) will go up
significantly and then go down (down - probably due to the garbage
collection). It is during those spikes caused by many users hitting wicket
pages
the os should be able to handle at least a few thousand open file handles.
furthermore you can configure it to have more if you need to. only one
handle should be open per resource (no way to avoid that) in a jar, so a
spike of user activity shouldnt affect this at all as resources cache
We have found a pretty weird situation with too many open files error on
our alpha-testing site. Further analysis showed that on each page refresh
the following resources get repeatedly obtained from the wicket's .jar and
add to the number of open files:
'wicket/ajax/wicket-ajax.js'
14 matches
Mail list logo
