[
https://issues.apache.org/jira/browse/CURATOR-443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16267563#comment-16267563
]
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_r153252872
--- 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 --
Why do we need to reinsert all of the operations? Isn't clearing the sleep
enough?
> 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)
