curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Drob (JIRA)" <>
Subject [jira] [Commented] (CURATOR-218) TreeCache initialization problem with non existant root path
Date Wed, 24 Jun 2015 23:09:04 GMT


Mike Drob commented on CURATOR-218:

So, I've continued digging into this, and I have good news! It has nothing to do with the

Unfortunately, it looks like there might be a bug in blockUntilConnected. I can file a new
JIRA, or rescope this one; whichever people prefer.

Given the following test code:
        CuratorFramework client;
        for(int i = 0 ; i < 50 ; i++)
            client = CuratorFrameworkFactory.newClient(server.getConnectString(), new RetryOneTime(100));
                Assert.assertTrue(client.getZookeeperClient().isConnected(), "Not connected
after blocking for connection #" + i);

I'll get an assertion failure fairly regularly. Here's the output in my logs from the test
run -

java.lang.AssertionError: Not connected after blocking for connection #3 expected [true] but
found [false]
	at org.testng.Assert.failNotEquals(
	at org.testng.Assert.assertTrue(
	at org.apache.curator.framework.imps.TestBlockUntilConnected.testBlockUntilConnectedTightLoop(

INFO  org.apache.curator.framework.imps.CuratorFrameworkImpl  Starting [main]
DEBUG org.apache.curator.CuratorZookeeperClient  Starting [main]
DEBUG org.apache.curator.ConnectionState  Starting [main]
DEBUG org.apache.curator.ConnectionState  reset [main]
INFO  org.apache.curator.framework.state.ConnectionStateManager  State change: CONNECTED [main-EventThread]
DEBUG org.apache.curator.framework.imps.CuratorFrameworkImpl  Closing [main]
DEBUG org.apache.curator.CuratorZookeeperClient  Closing [main]
DEBUG org.apache.curator.ConnectionState  Closing [main]

I understand that connections are a transient and finicky thing, like gold dust or rainbows,
they are apt to disappear when you least expect them to. However, I don't see anything given
by the CSM to indicate that we would _not_ be connected... no connection loss, no session
loss, nothing...

Anybody have a pointer on where to look next? I suspect that there is a synchronization issue
where the method returns before the state on CuratorZookeeperClient is updated, but I'm not
sure how to prove that yet.

Anyway, the TreeCache never sees that INITIALIZED event as the issue reported describes because
of the connection issue I described.

> TreeCache initialization problem with non existant root path
> ------------------------------------------------------------
>                 Key: CURATOR-218
>                 URL:
>             Project: Apache Curator
>          Issue Type: Bug
>          Components: Recipes
>    Affects Versions: 2.7.0, 2.7.1, 2.8.0
>         Environment: host: AWS EC2 t2.medium type
> uname -a = Linux bamboo-agent 3.13.0-44-generic #73-Ubuntu SMP Tue Dec 16 00:22:43 UTC
2014 x86_64 x86_64 x86_64 GNU/Linux
> lsb_release -a = 
> Distributor ID:	Ubuntu
> Description:	Ubuntu 14.04.1 LTS
> Release:	14.04
> Codename:	trusty
> ZK version: is a curator TestingServer
> java: java 8
> maven: 3.2.5
>            Reporter: Samuel García Martínez
>            Assignee: Scott Blum
>         Attachments: failing_test.txt
> I'm implementing a Guava service relying on the startAsync feature. I'm using a listener
to wait for the INITIALIZED event to fire the guava service notifyStarted method, but sometimes
the listener never receives the event if the root path does not exist.
> I've created a repository with a failing test (looping over the failing test to force
> repo with tests:
> failing test: mvn -Dtest=TreeCacheTest#testListenerNonExistentRootLoop test

This message was sent by Atlassian JIRA

View raw message