Tag: Java, Java / Home

Java

NAVIGATION
CATEGORIES
REFERRENCE
LINKS
Home » Java

  • Tapestry Perm Memory Leak and ThreadLocal

    7 answers - 1389 bytes - related search similar search Add To My Delicious Add To My Stumble Upon Add To My Google Mark Add To My Facebook Add To My Digg Add To My Reddit

    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

  • No.1 | | 257 bytes | |

    6/11/06, Cliff Zhao <zhaotq (AT) gmail (DOT) comwrote:
    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.

  • No.2 | | 972 bytes | |

    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 WRKING.

    I used JBSS 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

    6/11/06, Henri Dupre <henri.dupre (AT) gmail (DOT) comwrote:

    6/11/06, Cliff Zhao <zhaotq (AT) gmail (DOT) comwrote:

    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.
    --

  • No.3 | | 972 bytes | |

    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 WRKING.

    I used JBSS 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

    6/11/06, Henri Dupre <henri.dupre (AT) gmail (DOT) comwrote:

    6/11/06, Cliff Zhao <zhaotq (AT) gmail (DOT) comwrote:

    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.
    --

  • No.4 | | 191 bytes | |

    But how to do in jdk 1.4 ?
    To unsubscribe, e-mail: dev-unsubscribe (AT) tapestry (DOT) apache.org
    For additional commands, e-mail: dev-help (AT) tapestry (DOT) apache.org

  • No.5 | | 1465 bytes | |

    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?

    6/13/06, Cliff Zhao <zhaotq (AT) gmail (DOT) comwrote:

    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 WRKING.

    I used JBSS 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

    6/11/06, Henri Dupre <henri.dupre (AT) gmail (DOT) comwrote:

    6/11/06, Cliff Zhao <zhaotq (AT) gmail (DOT) comwrote:

    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.
    >
    >
    >
    >

  • No.6 | | 1610 bytes | |

    Tapestry jar files are in my war files.

    6/18/06, Henri Dupre <henri.dupre (AT) gmail (DOT) comwrote:

    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?
    --
    6/13/06, Cliff Zhao <zhaotq (AT) gmail (DOT) comwrote:

    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 WRKING.

    I used JBSS 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

    6/11/06, Henri Dupre <henri.dupre (AT) gmail (DOT) comwrote:

    6/11/06, Cliff Zhao <zhaotq (AT) gmail (DOT) comwrote:

    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.
    >
    >
    >
    >
    >
    >

  • No.7 | | 327 bytes | |

    6/18/06, Cliff Zhao <zhaotq (AT) gmail (DOT) comwrote:

    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


max 4000 letters.
Your nickname that display:
In order to stop the spam: 0 + 9 =
QUESTION ON "Java"

EMSDN.COM