[ 
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 <[email protected]>
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)

Reply via email to