[
https://issues.apache.org/jira/browse/TUSCANY-2630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12638098#action_12638098
]
Simon Nash commented on TUSCANY-2630:
-------------------------------------
Apologies for not considering the multi-threaded case when I wrote this caching
code. The fix seems fine. Callback wires can't be shared between callback
invocations because there is code in the callback path that modifies the wire
and/or its contents. The cache was intended to avoid the need to create a new
clone on every callback invocation between the same pair of components. It
will be less effective in this multi-threaded case than in a single-threaded
scenario, but it should still be better than not doing any caching.
> 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.
