[
https://issues.apache.org/jira/browse/ZOOKEEPER-666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12832405#action_12832405
]
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
scenario?
How about a builder-based approach instead? E.g,
{noformat}
ZooKeeper client = ZooKeeper.builder()
.timeout(...)
.watcher(...)
.connect(connectString);
{noformat}
This would make it possible to add future parameters without breaking the
public API, while preserving immutability semantics for initialization
parameters.
> 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.
