You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@curator.apache.org by "ASF GitHub Bot (JIRA)" <ji...@apache.org> on 2017/11/22 02:16:00 UTC
[jira] [Commented] (CURATOR-443) CuratorFrameworkImpl may sleep in
foreground even if inBackground is called
[ https://issues.apache.org/jira/browse/CURATOR-443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16261863#comment-16261863 ]
ASF GitHub Bot commented on CURATOR-443:
----------------------------------------
GitHub user Randgalt opened a pull request:
https://github.com/apache/curator/pull/242
[CURATOR-443] CuratorFrameworkImpl may sleep in foreground even if inBackground is called
To avoid massive spinning, background operations are paused for 1 second when there is no connection. However, this can hurt performance terribly if background operations are queued, for example, prior to initial connection. This changes the behavior so that the sleeps are cleared when the connection is re-established. A separate queue of "forced sleep" operations are kept while the connection is down. This queue then gets its sleep cleared when the connection is re-established.
Reviewers - please verify this logic. I think I have it right. I'm only concerned that I might be leaking operations into `forcedSleepOperations` that never get cleared.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/apache/curator CURATOR-443
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/curator/pull/242.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #242
----
commit bfdb790bc69022b0eef74558e9511e6ed2b665e9
Author: randgalt <ra...@apache.org>
Date: 2017-11-22T02:11:01Z
To avoid massive spinning, background operations are paused for 1 second when there is no connection. However, this can hurt performance terribly if background operations are queued, for example, prior to initial connection. This changes the behavior so that the sleeps are cleared when the connection is re-established. A separate queue of "forced sleep" operations are kept while the connection is down. This queue then gets its sleep cleared when the connection is re-established.
----
> CuratorFrameworkImpl may sleep in foreground even if inBackground is called
> ---------------------------------------------------------------------------
>
> 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)