Skip to content

Consider refactoring the usages of clusterService.addListener(this) #37861

@pgomulka

Description

@pgomulka

I noticed few implementations of ClusterStateListener registering itself to a ClusterService within constructor using a possibly dangerous construct:

   clusterService.addListener(this);

This is explicitly publishing this reference before the object is constructed. That can in turn lead to race conditions and visibility problems .

It is well described by Brian Goetz in his articles or in his book
sample article: https://www.ibm.com/developerworks/library/j-jtp0618/index.html

That is also mentioned in a java language specification JLS 17.5 final field semantics

An object is considered to be completely initialized when its constructor finishes. A thread that can only see a reference to an object after that object has been completely initialized is guaranteed to see the correctly initialized values for that object's final fields.
The usage model for final fields is a simple one: Set the final fields for an object in that object's constructor; and do not write a reference to the object being constructed in a place where another thread can see it before the object's constructor is finished. If this is followed, then when the object is seen by another thread, that thread will always see the correctly constructed version of that object's final fields. It will also see versions of any object or array referenced by those final fields that are at least as up-to-date as the final fields are.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions