On Tue, Oct 7, 2008 at 2:17 PM, Scott Kurz (JIRA) <[email protected]>wrote:
> > [ > https://issues.apache.org/jira/browse/TUSCANY-2630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12637471#action_12637471] > > Scott Kurz commented on TUSCANY-2630: > ------------------------------------- > > Thanks for taking a look. Not understanding this code real well, I have > to take it for granted that we have a good reason for not sharing the > callback wire across threads, (though I was half-wondering if that might > have been an old assumption that someone might realize is no longer needed). > > I don't know how to contribute a test showing this timing-dependent issue; > I have to use the debugger to step through to recreate. However, I would > say I've confirmed this fixes the leak in my environment. > > > > > memleak as RuntimeWireImpl callback cachedWire ref leaks due to clone() > impl > > > ---------------------------------------------------------------------------- > > > > Key: TUSCANY-2630 > > URL: https://issues.apache.org/jira/browse/TUSCANY-2630 > > Project: Tuscany > > Issue Type: Bug > > Components: Java SCA Core Runtime > > Reporter: Scott Kurz > > > > We can end up with an unbounded chain of RuntimeWireImpls because of the > way the 'cachedWire' field is handled to cache a callback wire. > > The problem arises with a sequence like: > > 1) Thread A calls CallbackReferenceImpl.getCallbackWire(), which results > in a wire.clone() and then the boundWire is "cached" via: > > ((RuntimeWireImpl)wire).addToCache(resolvedEndpoint, boundWire); > > 2) Thread B calls the same method on the same 'wire' instance, but > because the cachedWire is in-use, it does its own wire.clone(), > > making a shallow copy of wire's 'cachedWire'. > > 3) Only now does Thread A finish and call: > ((RuntimeWireImpl)wire).releaseWire(); (Nothing special happens here. > I'm just pointing out > > that since 2) happened first, the cached object was in-use and a new > clone was made. > > 4) When Thread B gets to the end of RuntimeWireImpl.cloneAndBind() it > calls: > > ((RuntimeWireImpl)wire).addToCache(resolvedEndpoint, boundWire); > > The net result is that the original wire has a ref, 'cachedWire' to the > clone made in Thread B, which in turn has a ref to the clone made from > Thread A. > > This illustrates the problem, as this can recursively grow unbounded. > > --------- > > A simple solution would seem to be to null out the 'cachedWire' field > towards the end of RuntimeWireImpl.clone(). Maybe there's an even better > one. > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. > IIRC it's because the callbacks for different threads can (will) have different destinations and hence the wires are configured differently. Simon
