Threadlocals in request-scope are diligently cleared at the end of each request in a finally block, so I doubt the problem is there. The problem is running out of permgen space, which is due to the generated proxies. If any instance or class hangs around after undeploying from a parent classloader (the famous commons-logging problem), the entire set of classes in the child classloader will stick around. So you run out of permgen on the 5th or 6th deploy.
Dhanji. On Tue, Oct 28, 2008 at 2:21 PM, Gili <[EMAIL PROTECTED]> wrote: > > Hi guys, > > I would appreciate your help commenting on this issue: > https://glassfish.dev.java.net/issues/show_bug.cgi?id=5104 > > The Glassfish guys have identified two memory leaks, one of which > results from Guice's use of thread-local storage. They're asking > questions about the Guice codebase. You know a lot more about this > code than I do so I would appreciate your feedback :) > > I will post a similar messages in the warp-persist mailing list. > > Thanks, > Gili > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "google-guice" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/google-guice?hl=en -~----------~----~----~----~------~----~------~--~---
