[
https://issues.apache.org/jira/browse/CURATOR-443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16267694#comment-16267694
]
ASF GitHub Bot commented on CURATOR-443:
----------------------------------------
Github user madrob commented on a diff in the pull request:
https://github.com/apache/curator/pull/242#discussion_r153341281
--- Diff:
curator-framework/src/main/java/org/apache/curator/framework/imps/CuratorFrameworkImpl.java
---
@@ -973,6 +981,33 @@ void performBackgroundOperation(OperationAndData<?>
operationAndData)
}
}
+ @VisibleForTesting
+ volatile long sleepAndQueueOperationSeconds = 1;
+
+ private void sleepAndQueueOperation(OperationAndData<?>
operationAndData) throws InterruptedException
+ {
+ operationAndData.sleepFor(sleepAndQueueOperationSeconds,
TimeUnit.SECONDS);
+ if ( queueOperation(operationAndData) )
+ {
+ forcedSleepOperations.add(operationAndData);
+ }
+ }
+
+ private void unSleepBackgroundOperations()
+ {
+ Collection<OperationAndData<?>> drain = new
ArrayList<>(forcedSleepOperations.size());
+ forcedSleepOperations.drainTo(drain);
+ log.debug("Clearing sleep for {} operations", drain.size());
+ for ( OperationAndData<?> operation : drain )
+ {
+ operation.clearSleep();
+ if ( backgroundOperations.remove(operation) )
--- End diff --
Ah, I'm with you now. Can you add a method comment that explains the nuance
of the implementation here?
If we're really concerned about ordering, then we could update clearSleep()
to set expiration time to the current time instead of setting it to zero.
> Sleep too long when connection to zookeeper has not been established yet
> after construction
> -------------------------------------------------------------------------------------------
>
> Key: CURATOR-443
> URL: https://issues.apache.org/jira/browse/CURATOR-443
> Project: Apache Curator
> Issue Type: Bug
> Components: Framework
> Affects Versions: 4.0.0
> Reporter: Duo Zhang
> Assignee: Jordan Zimmerman
> Fix For: 4.0.1
>
>
> Recently we purge the complicated RecoverableZooKeeper dependency in
> hbase-client and use curator to get data from zookeeper.
> But when debugging HBASE-19266, we found that if we get data immediately
> after the creation of CuratorFramework, the request will always cost 100x ms
> to complete.
> After digging, we found that there is a sleep in CuratorFrameworkImpl if the
> connection is not established yet
> https://github.com/apache/curator/blob/6d36a4793b31cdacaf4bbf6554e05d68bc680001/curator-framework/src/main/java/org/apache/curator/framework/imps/CuratorFrameworkImpl.java#L943
> This is really a bad news for us. We decide to make the async hbase client
> fully asynchronous. You can see this example, where we execute the request to
> hbase directly in the netty event loop thread.
> https://github.com/apache/hbase/blob/master/hbase-examples/src/main/java/org/apache/hadoop/hbase/client/example/HttpProxyExample.java
> So if there is a sleep in foreground then the event loop will be stuck for 1
> second which will cause very bad performance impact...
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
