On Thu, Jul 23, 2009 at 9:25 PM, Simon Laws<[email protected]> wrote: > Thanks for the summary Raymond. > >> >> Are you saying the thread local variable is not released? I searched the >> usages of the ThreadMessageContext in our code, all 3 cases are like: > > Yes. I don't see a ThreadLocal.remove() in the codebase. I'm guessing > but thread pooling the the container could result in the MessageImpl > instance sittings on the thread with a reference, via its class, to > the WebAppClassloader after the app has been stoppped. Hence the > classloader will not be GCd and we blow perm gen. > >> >> Message msgContext = ThreadMessageContext.getMessageContext(); // Get >> existing value [1] >> ... >> ThreadMessageContext.setMessageContext(msg); // Set to new value [2] >> try { >> ... >> } finally { >> ThreadMessageContext.setMessageContext(msgContext); // Reset to old value >> [3] >> } >> >> But [1] has some issues because it creates default value (I don't know why >> it is not null). >> protected synchronized Message initialValue() { >> Message msg = new MessageImpl(); >> msg.setFrom(new EndpointReferenceImpl("/")); >> return msg; >> } >> >> Is the dummy message leaking? > > Not sure. I think it's just whatever we put in thread local. > > I'll trying adding a "remove" to the ThreadMessageContext interface > and calling that when the webapp goes down. > >> >> BTW, we are also missing a check in >> org.apache.tuscany.sca.core.context.impl.CallableReferenceImpl.resolve(). >> >> else if (compositeActivator == null) { // Only get the composite activator >> when it is not set, the current code always looks for the thread local which >> is not performed >> this.compositeActivator = >> CompositeContext.getCurrentCompositeActivator(); >> if (this.compositeActivator != null) { >> this.proxyFactory = >> this.compositeActivator.getCompositeContext().getProxyFactory(); >> } >> } >> >> We should fix that too. >
OK so that is a step in the right direction. I'll check that change in and we can get it tried out. Simon
