jmx-dev Review Request: 7195779 javax/management/remote/mandatory/threads/ExecutorTest.java fail intermittently

Alan Bateman Alan.Bateman at oracle.com
Tue Oct 2 06:38:13 PDT 2012


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

-Alan


More information about the serviceability-dev mailing list