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
