Thanks for the explanation I think that helps shed some light... The
tests are actually JMeter tests driving load by emulating a web
browser - the application the are testing is running in Deployment
mode set up as though it were a production server. After a little more
digging I have been able to determine that is only a problem on pages
which use Ajax - and it looks like there is a related debug message
coming from an exception handler regarding the wicket-event.js file
not being accessible (URI is not hierarchical). This would actually
explain why the problem only manifests when the JMeter tests are set
to request embedded assets as wicket ajax pages embed requests for
additional pieces of javascript - which in the case of wicket-event.js
are causing exceptions to be thrown and the JVM bug you mentioned is
probably preventing these resources from being cleaned up properly.
Does that sound right?
Adam
On Oct 20, 2009, at 8:41 PM, Igor Vaynberg wrote:
when you are requesting an embedded resource wicket needs to stream
the file out of a jar, the way the jvm handles that is by creating a
jar url connection object that streams the file. unfortunately, there
is a bug in the jdk where the url connection does not have a close
method and so wicket or any other java app cannot release the
connection. this is addressed, afair, in jdk 7.
i have many apps deployed in production and have not managed yet to
run out of the handles with the limit set about 4K. not sure why this
is different in your case. you mentioned "tests", are those unit tests
and is wicket there running in deployment mode?
the resource watcher, which should be disabled, will cause the handles
to run out because it continuously monitors markup files for changes
(hot reloading in dev mode) and everytime it checks a markup file in a
jar it creates the url connection and leaks it. by default it is
disabled in deployment mode but if you manually set the poll frequency
in your settings it will be reenabled.
-igor
On Tue, Oct 20, 2009 at 4:07 PM, Adam Bender <a...@magpieti.com>
wrote:
We have run with a limit as high as 10,000 files and our tests can
bring it
to the limit in 20 minutes, but that still doesn't explain why so
many
copies of the jar are needed - and only when we are also requesting
embedded
assets...
On Oct 20, 2009, at 5:04 PM, Major Péter wrote:
resolution -> solution...
Just set the ulimit in the initscript and run it with start-stop-
daemon,
it will make the problem disappear (but still there would be many
open
files...)
Peter
2009-10-21 00:38 keltezéssel, Major Péter írta:
Hi,
we also had this issue, because (I think) we are running two
different
wicket application in only one glassfish domain. Our resolution
was,
that we are running now the glassfish domains with custom init
scripts
with ulimit settings. Maybe this will help for you.
Best Regards,
Peter
2009-10-21 00:14 keltezéssel, Martin Grigorov írta:
Hi Adam,
You may try to debug what is the problem with
https://wiki.sdn.sap.com/wiki/display/Java/JPicus
El mar, 20-10-2009 a las 15:39 -0600, Adam Bender escribió:
Greetings all,
Recently I have been performance testing a Wicket application
(1.4.1)
and I
am running into the dreaded Too Many Files Open issue. I have
searched
the
mailing lists and most of the trouble around this issue seems
to come
from
being in DEVELOPMENT mode so I made sure we were in DEPLOYMENT
mode.
When I
run 'lsof -p xxxx | grep wicket-1.4.1.jar' I see over 1000
entries and
it's
growing monotonically. This seems really unusual - why would
wicket
need
1000 copies of this jar open? An additional bit of weirdness
came up
when
our load tests stopped loading the embedded assets (css, js and
images)
in
each page - this seemed to cap the number of lsof entries at
5... This
is
even weirder because our app serves these static items from httpd
without
tomcat ever knowing about them. How could our loading of
embedded items
really affect the number of file handles wicket needs?
For completeness we are running this app on Red Hat Enterprise
Linx 5
with
Tomcat 6.0.20 and Java 1.6
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
