RFR(s): 8023541 Race condition in rmid initialization
Alan Bateman
Alan.Bateman at oracle.com
Wed Jan 29 09:29:26 UTC 2014
On 29/01/2014 06:51, Stuart Marks wrote:
> Hi all,
>
> Please review this fix to a race condition in rmid initialization.
> Briefly, rmid subclasses the RMI registry implementation and provides
> special handling for its own stub. Unfortunately the registry is
> exported in the super() call, making remote calls possible before
> rmid's stub initialization is complete. The fix is to ensure that all
> remote calls wait for initialization before proceeding.
>
> Bug:
>
> https://bugs.openjdk.java.net/browse/JDK-8023541
>
> Webrev:
>
> http://cr.openjdk.java.net/~smarks/reviews/8023541/webrev.0/
>
This looks okay as an initial fix but I just wonder about every bind and
lookup now needing to synchronize in order to check if has initialized.
I don't know the full background to this one and maybe you have
experimented with other solutions. I just wonder if you could change
initialized to volatile and only synchronize/wait when false? That way
you would only be adding a read of a volatile. I assume the stub can
never be null so maybe it could be changed to volatile and only wait if
null (the initialized flag could go away then).
One other comment (assuming the current approach goes ahead) is that you
could change lookup, bind, unbind so that they only await when the
name is not ActivationSystem. Also list doesn't appear to need the stub
so maybe the await is not needed there.
-Alan.
More information about the core-libs-dev
mailing list