Re: Tapestry Perm Memory Leak and ThreadLocal

2006-06-18 Thread Henri Dupre

On 6/18/06, Cliff Zhao <[EMAIL PROTECTED]> 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

2006-06-18 Thread Cliff Zhao

Tapestry jar files are in my war files.

On 6/18/06, Henri Dupre <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote:
> >
> > On 6/11/06, Cliff Zhao <[EMAIL PROTECTED]> 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

2006-06-18 Thread Henri Dupre

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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote:
>
> On 6/11/06, Cliff Zhao <[EMAIL PROTECTED]> 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

2006-06-13 Thread Cliff Zhao

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 <[EMAIL PROTECTED]> wrote:


On 6/11/06, Cliff Zhao <[EMAIL PROTECTED]> 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.