On Tue 02 Oct 2012 03:38:13 PM CEST, Alan Bateman wrote: > On 02/10/2012 09:33, Jaroslav Bachorik wrote: >> : >> The generated TIE class is inherently thread-unsafe. The internal state >> (the target field) can be manipulated without any enforced >> synchronization - eg. it is valid to set the target field to null by >> calling the deactivate() method after the _invoke() method has been >> entered from a different thread. This will lead to the NPE we can >> observe. Given this example one should make critical sections out of >> deactivate() and _invoke() methods to prevent this situation. However, >> this simplistic approach might lead to deadlocks in the existing code >> as the _invoke() method body might be blocking (it is a 3rd party code) >> and thus preventing execution of the deactivate() method indefinitely. >> >> Also, it is not really possible to solve this problem outside of the >> generated TIE class - it is caused by the concurrent change of the >> TIE's internal state. So, the solution would be either caching the >> target attribute at the beginning of the invoke() operation in a >> synchronized block and use the cached version afterwards (and throwing >> a remote exception if it is null - the TIE was deactivated effectively >> before entering the invoke() operation) or postponing deactivation when >> the invoke() method is detected as being in progress. >> >> -JB- >> > Jaroslav and I chatted on IM about this today. Jaroslav is going to > have a go at changing the stub generator and will send a follow-up > mail with an updated webrev (this time for the corba repo as the that > is where the stub generator lives).
This is a follow-up. I've prepared the patch and put it on github - https://github.com/jbachorik/openjdk-patches/tree/master/webrevs/7195779 I wonder who else should be included in the review process since I am changing the IIOP generator code. Also, I didn't find any tests in the corba repository. Which test suite is appropriate to run after changing the corba related code? -JB- > > -Alan
