run-app not releasing memory after compilation

You can verify whether this is related to the reloading agent by starting Grails with grails -noreloading ....

Yep, using grails -noreloading ... fixes the problem.

Andy - seems to be spring loaded related, could you take a look?

@Paul - want to email me a copy of the app? aclement AT vmware.com - it would be useful to profile it. I think I know what is happening but just want to confirm.

Andy,

Setting up the full app would take you for ever and a day. If you look at GRAILS-8208 you will see that I've just uploaded a small STS project called test. Even though it's small it still exhibits the 'runs like a dog' symptoms to a noticeable degree, even if not quite as extreme as the full app.

thanks, i'll take a look.

not having much luck recreating so far. Using the test app from GRAILS-8208.

grails clean

timed:

grails compile
grails run-app

and "Server running. Browse to http://localhost:8080/test" appears after ~40s

grails clean

timed:

grails run-app

and "Server running. Browse to http://localhost:8080/test" appears after ~30s

I'm not looking at heap, just time. Xmx/permgen are the same as what you have, the default. I'm on a mac on Java6 though.

Can you confirm the steps above should be showing me the problem? I'll give it a go on Java7.

Your two scenarios are valid. Your timings obviously suggest that the compilation phase is not a problem although maybe it takes the full application to stress it sufficiently for a slow-down to appear. Nevertheless, even in the test app, if you move around the application (adding a new Author, Book, Pamphlet etc) you should see a difference between the first scenario and the second. If you don't then it must either be Java 7 (which seems unlikely since everything seemed ok under 2.0.0.M1 with Java 7) or my machine (which uses Windows 7 after all!)

One thing I can add is that using a clean/run-app with the full application sometimes won't even compile at all. It falls over with all sorts of odd messages. The only other factor which seems to upset things is when Grails updates its list of current plugins (which it seems to do with alarming frequency). Whenever I see it do this, I shut the app down and re-start it to avoid any potential problems - or maybe I'm just getting paranoid!

Andy, you could try the infamous grails-website app (you should be OK with the latest code on the grails-1.4 branch and Grails 2.0.0.RC1). I run it with these settings:

-Xms128m -Xmx384m -XX:MaxPermSize=256m

Now, if I do grails clean and then grails run-app, the server doesn't even manage to start up! But if I do a subsequent run-app, it starts fine and the application works. This appears to be an artifact of the compilation phase grabbing but not releasing memory. Let me know if you can reproduce or if you run into any other problems with the app.

Just wanted to add that I'm seeing the same issue Paul reported. The main differences between the environment Paul reported using and my development environment are: the project I'm trying to upgrade to 2.0.0.RC1 is a bit larger (i.e. 200+ domain classes), Java is 1.6.0_26, and system is running Win 7 32-bit.

Executing grails clean and then grails run-app on the grails 1.3.7 version of the project with JAVA_OPTS -XX:PermSize=256m -Xmx1024m worked as expected, but the same procedure on 2.0.0.RC1 spikes the memory usage up to the max heap size when starting up the app, causing severe performance issues using the application.

Unfortunately, I've not yet been able to confirm that grails -noreloading fixes the problem since I'm now running into the Tomcat bug http://jira.grails.org/browse/GRAILS-8287 preventing the application from running when I try and run grails compile before grails run-app.

Phil/Paul - we've not been able to reproduce the behavior your are seeing. In order to see progress on this issue we're going to need an example application that exhibits the problem.

Graeme,

If the small app I uploaded doesn't exhibit the problem for you, and if the problem that Peter identified is not the same issue, then I'm at a bit of a loss as to what to do. Unless Phil has any additional information then I suggest you close this issue and we'll see what happens with the next release.