Martin Traverso commented on ZOOKEEPER-666:

Indeed, breaking backward-compatibility would be a big issue.

One drawback I see with 2b is that the API would seem to allow calling those 
methods after connect() has been called. What would the semantics be in that 

How about a builder-based approach instead? E.g,

ZooKeeper client = ZooKeeper.builder()

This would make it possible to add future parameters without breaking the 
public API, while preserving immutability semantics for initialization 

> Unsafe publication in client API
> --------------------------------
>                 Key: ZOOKEEPER-666
>                 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-666
>             Project: Zookeeper
>          Issue Type: Bug
>          Components: java client
>    Affects Versions: 3.2.2
>            Reporter: Martin Traverso
>             Fix For: 3.3.0
> The following code may result in a data race due to unsafe publication of a 
> reference to "this". The call to cnxn.start() spawns threads that have access 
> to the partially-constructed reference to the ZooKeeper object. 
> See http://www.ibm.com/developerworks/java/library/j-jtp0618.html for some 
> background info.
> {noformat}
> public ZooKeeper(String connectString, int sessionTimeout, Watcher watcher)
>     throws IOException
> {
>         .....
>         cnxn = new ClientCnxn(connectString, sessionTimeout, this, 
> watchManager);
>         cnxn.start();
> }
> {noformat}
> The obvious fix is to move the call to cnxn.start() into a separate start() 
> method.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

Reply via email to