[
https://issues.apache.org/jira/browse/TUSCANY-2630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12637414#action_12637414
]
ant elder commented on TUSCANY-2630:
------------------------------------
The simple solution you propose looks ok to me but other than ensuring the
build still works it would be hard for me to test as its quite a complicated
scenario. Any chance you could provide a testcase demonstrating the issue? If
its a lot of work to make your test contributable how about you just make the
change locally yourself and confirm it fixes the leak in your 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.
