I'm testing a Tapestry app running under Jetty on Windows using multiple Selenium IDE sessions and have noticed a creep of about 130MB RAM per hour on my java exe when running through a test loop that logs in to the app, runs through some expected user behaviour (some search screens, detail screens, minor amounts of data entry / persistence) and then logs out. Each test loop iteration takes about 40 seconds. Upon log out, the http session is destroyed and I am running six concurrent sessions at the moment. The test script does not vary the entities retrieved from the database so beyond the initial entity caching I would not expect the memory usage to keep increasing, i.e. it should bottom out at some stage.
I've found this with T.5.2.0 and also T.5.2.1, and the current JVM I'm using is from jdk1.6.0_21_x64 on Jetty 6.1.18. I'm working my way through different JVMs at the moment to see if there is much of a difference. Given that the entities loaded are the same during the test loops, the HTTP session is destroyed during each loop cycle, and the memory footprint appears to stay at the same level after the tests are stopped, could anyone give any pointers to Tapestry areas to look at to try to identify the cause of the memory creep? Or perhaps this is a JVM / Jetty issue? Having trawled through the list before on related GC issues, I'm using the following JVM settings: -server -Xms1408m -Xmx1536m -XX:MaxPermSize=256m -XX:NewSize=384m -XX:SurvivorRatio=2 With such a noticeable creep (initially approx 650MB with 6 sessions rising to 780MB after 1 hour) reproducible on a dev machine I'm concerned that this app won't make it out of dev unless I can get to the bottom of the problem. Regards, Jim.
