You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Cliff Zhao <zh...@gmail.com> on 2006/06/11 06:15:33 UTC

Tapestry Perm Memory Leak and ThreadLocal

Everytime I re-deploy my application, the JVM Perm Memory will increase
about 4.5MB, it's never reclaimed by the JVM, and at end I have to restart
my application server.

I have followed up and researched this issue quite a while. I read the
Hivemind code around Thread Cleanup; I also read the source code of
java.lang.ThreadLocal. Here are my findings (theoretically, not verified in
practice):
I think that the ThreadLocals are causing the Perm memory leak.
   In the Hivemind ThreadedServiceModel, the ThreadLocal's content is set to
null when doing thread cleanup. But this does not remove the ThreadLocal
variable from the thread's local map. The ThreadLocal will never be
released. This will prevent the ear class loader from being
garbage-collected. In JDK5.0, a new method is added into ThreadLocal class:
remove; which will truely remove the ThreadLocal variable from the thread's
local map.

Could Tapestry/Hivemind developers (may be Howard) verify my investigation
and make a Hivemind build for JDK5.0 to remove the memory leak? It's just
one line change in ThreadedServiceModel.java:
    private void unbindServiceFromCurrentThread()
    {
        _activeService.set(null); //  change to _activeService.remove();
    }

Any thoughts?

Thanks.

Best Regards,
Cliff Zhao

Re: Tapestry Perm Memory Leak and ThreadLocal

Posted by Henri Dupre <he...@gmail.com>.
On 6/18/06, Cliff Zhao <zh...@gmail.com> wrote:
>
> Tapestry jar files are in my war files.


That is then surprising... Why would you be affected with your own
ThreadLocal but not the ones from Tapestry and Hivemind (none of them are
calling ThreadLocal.remove())?

Thanks,

Henri.

Re: Tapestry Perm Memory Leak and ThreadLocal

Posted by Cliff Zhao <zh...@gmail.com>.
Tapestry jar files are in my war files.

On 6/18/06, Henri Dupre <he...@gmail.com> wrote:
>
> This is very interesting... I don't have any threadlocal in my app but at
> every redeployment the memory is increasing. I had a quick look at the
> tapestry source code and there is a bunch of ThreadLocal.set(null). But it
> seems that in your case, they are not affecting the perm memory?
> Where are your tapestry jar files? Are they inside the war or in common?
>
>
> On 6/13/06, Cliff Zhao <zh...@gmail.com> wrote:
> >
> > I did some tests and the results are very promising.
> >
> > I use one ThreadLocal variable in my Tapestry application. It took about
> > 4.5MB for every re-deployment from Perm Memory and never went down.
> After
> > I
> > changed the ThreadLocal.set(null) to ThreadLocal.remove(), the Perm
> Memory
> > was stablized at 31MB. My theory is WORKING.
> >
> > I used JBOSS 4.0.4.GA Patch 1 and JDK5.0 Update 7 on Windows XP.
> >
> > I strongly suggest to use ThreadLocal.remove() instead of
> > ThreadLocal.set(null).
> >
> >
> > I think that people will be interested in the findings, so, I send it to
> > both lists.
> >
> > Best Regards,
> > Cliff Zhao
> >
> > On 6/11/06, Henri Dupre <he...@gmail.com> wrote:
> > >
> > > On 6/11/06, Cliff Zhao <zh...@gmail.com> wrote:
> > > >
> > > > Any thoughts?
> > >
> > >
> > > In the tomcat faq, they say that this is a classloader issue and
> cannot
> > be
> > > solved.
> > > Not sure how the threadlocals affect that...
> > >
> > > Thanks,
> > >
> > > Henri.
> > >
> > >
> >
> >
>
>
> --
> Thanks,
>
> Henri.
>
>

Re: Tapestry Perm Memory Leak and ThreadLocal

Posted by Henri Dupre <he...@gmail.com>.
This is very interesting... I don't have any threadlocal in my app but at
every redeployment the memory is increasing. I had a quick look at the
tapestry source code and there is a bunch of ThreadLocal.set(null). But it
seems that in your case, they are not affecting the perm memory?
Where are your tapestry jar files? Are they inside the war or in common?


On 6/13/06, Cliff Zhao <zh...@gmail.com> wrote:
>
> I did some tests and the results are very promising.
>
> I use one ThreadLocal variable in my Tapestry application. It took about
> 4.5MB for every re-deployment from Perm Memory and never went down. After
> I
> changed the ThreadLocal.set(null) to ThreadLocal.remove(), the Perm Memory
> was stablized at 31MB. My theory is WORKING.
>
> I used JBOSS 4.0.4.GA Patch 1 and JDK5.0 Update 7 on Windows XP.
>
> I strongly suggest to use ThreadLocal.remove() instead of
> ThreadLocal.set(null).
>
>
> I think that people will be interested in the findings, so, I send it to
> both lists.
>
> Best Regards,
> Cliff Zhao
>
> On 6/11/06, Henri Dupre <he...@gmail.com> wrote:
> >
> > On 6/11/06, Cliff Zhao <zh...@gmail.com> wrote:
> > >
> > > Any thoughts?
> >
> >
> > In the tomcat faq, they say that this is a classloader issue and cannot
> be
> > solved.
> > Not sure how the threadlocals affect that...
> >
> > Thanks,
> >
> > Henri.
> >
> >
>
>


-- 
Thanks,

Henri.

Re: Tapestry Perm Memory Leak and ThreadLocal

Posted by jone <jo...@yahoo.com.cn>.
But how to do in jdk 1.4 ?


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org


Re: Tapestry Perm Memory Leak and ThreadLocal

Posted by Cliff Zhao <zh...@gmail.com>.
I did some tests and the results are very promising.

I use one ThreadLocal variable in my Tapestry application. It took about
4.5MB for every re-deployment from Perm Memory and never went down. After I
changed the ThreadLocal.set(null) to ThreadLocal.remove(), the Perm Memory
was stablized at 31MB. My theory is WORKING.

I used JBOSS 4.0.4.GA Patch 1 and JDK5.0 Update 7 on Windows XP.

I strongly suggest to use ThreadLocal.remove() instead of
ThreadLocal.set(null).


I think that people will be interested in the findings, so, I send it to
both lists.

Best Regards,
Cliff Zhao

On 6/11/06, Henri Dupre <he...@gmail.com> wrote:
>
> On 6/11/06, Cliff Zhao <zh...@gmail.com> wrote:
> >
> > Any thoughts?
>
>
> In the tomcat faq, they say that this is a classloader issue and cannot be
> solved.
> Not sure how the threadlocals affect that...
>
> Thanks,
>
> Henri.
>
>

Re: Tapestry Perm Memory Leak and ThreadLocal

Posted by Cliff Zhao <zh...@gmail.com>.
I did some tests and the results are very promising.

I use one ThreadLocal variable in my Tapestry application. It took about
4.5MB for every re-deployment from Perm Memory and never went down. After I
changed the ThreadLocal.set(null) to ThreadLocal.remove(), the Perm Memory
was stablized at 31MB. My theory is WORKING.

I used JBOSS 4.0.4.GA Patch 1 and JDK5.0 Update 7 on Windows XP.

I strongly suggest to use ThreadLocal.remove() instead of
ThreadLocal.set(null).


I think that people will be interested in the findings, so, I send it to
both lists.

Best Regards,
Cliff Zhao

On 6/11/06, Henri Dupre <he...@gmail.com> wrote:
>
> On 6/11/06, Cliff Zhao <zh...@gmail.com> wrote:
> >
> > Any thoughts?
>
>
> In the tomcat faq, they say that this is a classloader issue and cannot be
> solved.
> Not sure how the threadlocals affect that...
>
> Thanks,
>
> Henri.
>
>

Re: Tapestry Perm Memory Leak and ThreadLocal

Posted by Henri Dupre <he...@gmail.com>.
On 6/11/06, Cliff Zhao <zh...@gmail.com> wrote:
>
> Any thoughts?


In the tomcat faq, they say that this is a classloader issue and cannot be
solved.
Not sure how the threadlocals affect that...

Thanks,

Henri.