Mem Leaks in Labs

[dsicore]

I'm seeing some nasty leaks in Labs on our dev box. Also, I've been graphing out the GC stats on our prod machine as well.. and we are going to encounter problems soon.

See:

http://labs.jboss.com/portal/jbosslabs/gcdata

The removal of the ejb3 timer service solved one problem, but now something else is biting us.

I have a few questions about the ForgeManagement and related services. I'm wondering if things are being cached and never removed. In particluar:

portal-extensions/forge-common/src/java/org/jboss/forge/common/se
rvice/ForgeManagement.java

There's a method to add something to the cache, but never remove it.

Are we continually adding but not evicting? I'm still looking into it.

Any comments appreciated.

[adamw]

Hello,
about ForgeManagement - yes, there aren't any functions to remove a cached item. But, if you look at the actual implementation and usage, you'll see that cache items are replaced. So, at startup, there's a (for example) ProjectDescriptor put into the cache, and then, if there are any changes in project.xmls, replaces the old one in the map with a new one. So these items are, you can say, "constant" in cache, and shouldn't cause mem leaks. Especially that this works since July I think, and we are seeing the leaks only lately, so it must be some of the new things :).

--
Cheers,
Adam

[starksm64]

Can you create a jira issue with an example of the timer creation usage and assign it to Dimitris so he can look into it as he has reworked the timer layer and we need to validate there is no leak there. If that does not show anything, then we need some profile data the illustrates when the issue looks to be.

http://jira.jboss.com/jira/browse/JBAS

[adamw]

Hello,
maybe I'll let Damon create the issue, but about the timers: now they are simple threads - we switched from ejb3 timers as they were leaking memory even faster. So the code is:

 new Thread() {
 {
 setDaemon(true);
 }

 public void run() {
 while (true) {
 try {
 sleep(getTimerInterval());
 } catch (InterruptedException e) {
 e.printStackTrace();
 }

 update();
 }
 }
 }.start();

But, as I said earlier, there's nothing changed in the service code, except moving invocation of update() method from ejb3 timer to the thread above. And we are getting these memory leaks only in last week or two.

--
Cheers,
Adam

[dsicore]

Yeah... I dont' think the problem is in our timers. I really think it is somewhere else. I was only using those timers as an example of what we should be looking for. :]

I'll create the bug report for the EJB3 timer, don't worry about it, Adam.

We still have Kosmos to worry about. ;)