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
