[
https://issues.apache.org/jira/browse/HBASE-15292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15229126#comment-15229126
]
Ted Yu commented on HBASE-15292:
--------------------------------
{code}
+class InstancePending<T> {
{code}
Add javadoc and audience annotation to the class.
{code}
+ if (interrupted) {
+ Thread.currentThread().interrupt();
{code}
Call to Thread.currentThread().interrupt() can be performed inside the catch
block - this would save variable interrupted.
{code}
+ instanceHolder = this.instanceHolder;
+ assert instanceHolder != null;
{code}
One way of calming findbugs is to use (instanceHolder != null) as condition for
the while loop.
{code}
+class PendingWatcher implements Watcher {
{code}
Add javadoc and audience annotation to the class.
Actually can PendingWatcher be omitted ?
InstancePending is generic and the two methods PendingWatcher overrides are
one-liner.
After the change, "hbase.zookeeper.watcher.sync.connected.wait" is dropped.
Should the loop in InstancePending#get() be passed a timeout so that the above
config is still respected ?
> Refined ZooKeeperWatcher to prevent ZooKeeper's callback while construction
> ---------------------------------------------------------------------------
>
> Key: HBASE-15292
> URL: https://issues.apache.org/jira/browse/HBASE-15292
> Project: HBase
> Issue Type: Bug
> Components: Zookeeper
> Reporter: Hiroshi Ikeda
> Assignee: Hiroshi Ikeda
> Priority: Minor
> Attachments: HBASE-15292-V2.patch, HBASE-15292-V3.patch,
> HBASE-15292-V4.patch, HBASE-15292.patch
>
>
> The existing code is not just messy but also contains a subtle bug of
> visibility due to missing synchronization between threads.
> The root of the evil is that ZooKeeper uses a silly anti-pattern, starting a
> thread within its constructor, and in practice all the developers are not
> allowed to use ZooKeeper correctly without tedious code.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
