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.
