[jira] Commented: (TUSCANY-2630) memleak as RuntimeWireImpl callback cachedWire ref leaks due to clone() impl

["ant elder (JIRA)" <de...@tuscany.apache.org>]

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