ZK - Open Source Ajax Java Framework

Hi,

I am observing memory leaks when redeploying my ZK web app in JBoss 5.1.0GA (no Spring). The ZK uses ThreadLocal data extensively, but do not clean them in ServletContextListener.contextDestroyed() and I guess it might be the main source of the problem.

Check similar Spring issue:
http://opensource.atlassian.com/confluence/spring/display/DISC/Memory+leak+-+classloader+won%27t+let+go

Also, the other source of the problem may be commons-logging (maybe SLF4J fixed this problem).

Did somebody else experience memory leaks after redeploy? Is this ZK bug or the problem is somewhere else?

Technically, ZK cleans up each ThreadLocal variable after serving a request. To really know the real cause, we have to use jprofiler or other tools to verify.

Regarding ServletContextListener, we clean up the application when DHtmlLayoutServlet's destroy method is called. It shall have the same effect.

And do you observe memory leaks after redeploy, too?

Hi,

I have used Eclipse MAT and found, that there are some CacheMap objects in the ThreadLocal variables. I suspect the class ThreadLocalCache - it never calls ThreadLocal.remove() method.

Again, I do not see ZK using ThreadLocal.remove() in many other cases, too. So, how and where does ZK clean ThreadLocal variables?

Hi Ondrej,

Could you provide the log of Eclipse MAT? As far as I know we don't have memory leak issue when redeploying on Tomcat. However, I am not sure if the redeployment is going thru Eclipse -- I don't trust Eclipse's memory use. I don't have Eclipse but many of others have to restart Eclipse once a while to clean up.

ZK doesn't call ThreadLocal.remove(). It is supposed to be garbage collected if all classes are unloaded completely (so all references to it are gone)

Hi Tom,

I use JBoss tool in Eclipse to redeploy my web app. This tool just makes a simple file copy. The problem remains also when I redeploy my web app manually. I use exploded deployment. to reproduce the bug, try:
1. copy exploded deployment,
2. run the app (point browses to the proper url)
3. delete the deployment
4. repeat 1. - 3. few times

Maybe the problem is caused by this?

Probem with static ThreadLocal (ZK uses that):
- http://blog.arendsen.net/index.php/2005/02/22/threadlocals-and-memory-leaks-revisited/
- http://www.jroller.com/tackline/entry/fixing_threadlocal
Problem with inner classes and ThreadLocal: http://crazybob.org/2006/02/threadlocal-memory-leak.html

How to clean ThreadLocals in a servlet: http://www.dewavrin.info/?p=196

My heap dump is at:
http://dl.dropbox.com/u/1372480/dump_simple.hprof (206MB, will be deleted later).

I just have started Eclipse MAT and used the function: "Duplicate Classes: Detect classes loaded by multiple class loaders."

Interesting! You're probably right. I'll investigate it a bit more later. Thanks.

I have made a bug for this issue Bug ID 2961772

Thanks. We will follow it there.

@xmedeko
Tom has modified the code lately.
And the issue should be resolved.

Due to some soft reference may not be garbage collected while redeploy,
you may add following setup to jboss vm arguments.
XX:SoftRefLRUPolicyMSPerMB=1

@PeterKuo
I have downloaded the latest ZK 3.6.4 and do not see the Bug ID: 2961772 in the release-notes. Has it been fixed in 3.6.4, too, or just in the 5.0.1?
Thx

@xmedeko
Thanks for your notification,
It has been fixed in both versions.

Hi Peter,
I still see memory leaks with ZK 3.6.4 after I redeploy an application (duplicate classes in Eclipse MAT). I suspect the ScalableTimer in the SmartAuWriter. Is it the possible cause of a memory leak or should I look somewhere else?

Thanks

Though it's fixed, but may not be updated to release so fast?

BTW, have you gc soft reference before? As I mentioned
"Due to some soft reference may not be garbage collected while redeploy,
you may add following setup to jboss vm arguments.
XX:SoftRefLRUPolicyMSPerMB=1"

@xmedeko
Would you please turn off ScalableTimer and try again?
Please refer to
http://docs.zkoss.org/wiki/Developer_reference_Appendix_B._WEB-INF/zk.xml_Overview_The_client-config_Element#The_resend-delay_Element
and set the value to -1

Also, can you provide a most easy sample to let us reproduce the problem?

@PeterKuo
Yes, with this parameter the redeploy seems has no memory leaks.

The sample is the same as before: deploy an ZK app with SmartAuWriter turned on, hit the app URL in the browser, undeploy the app. Repeat a few times. Start jconsole, click garbage collecting a few times (to be sure soft references are gone), dump live objects (jps;jmap -dump:live,file=dump.hprof PID), see the dump.hprof in Eclipse MAT.

Maybe the thread of the ScalableTimer has to be destroyed before undeploying the application? I think it has something to do with the Java classloader hell and static variables.

Ondrej, I think you're right. I'll fix it later. Meanwhile, if it is an issue to you, disable the timer as Peter suggested.

Thanks Tom, our project is still in developing phase, so I keep timer disabled, no problem.

Fixed but wait for our next freshly release: detail.

Is this memory leak issue related to "premgen space" ?
afaik, this is in the jvm level memory management, people suggest to use jrockit form oracle, the said it has better memory mgt.
cmiiw