[
https://issues.apache.org/jira/browse/CURATOR-218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14600340#comment-14600340
]
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 TreeCache!
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:
{code}
CuratorFramework client;
for(int i = 0 ; i < 50 ; i++)
{
client =
CuratorFrameworkFactory.newClient(server.getConnectString(), new
RetryOneTime(100));
try
{
client.start();
client.blockUntilConnected();
Assert.assertTrue(client.getZookeeperClient().isConnected(),
"Not connected after blocking for connection #" + i);
}
finally
{
client.close();
}
}
{code}
I'll get an assertion failure fairly regularly. Here's the output in my logs
from the test run -
{noformat}
java.lang.AssertionError: Not connected after blocking for connection #3
expected [true] but found [false]
at org.testng.Assert.fail(Assert.java:94)
at org.testng.Assert.failNotEquals(Assert.java:494)
at org.testng.Assert.assertTrue(Assert.java:42)
at
org.apache.curator.framework.imps.TestBlockUntilConnected.testBlockUntilConnectedTightLoop(TestBlockUntilConnected.java:251)
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]
{noformat}
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: https://issues.apache.org/jira/browse/CURATOR-218
> 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 it).
> repo with tests:
> https://github.com/samuelgmartinez/curator-treecache-tests.git
> failing test: mvn -Dtest=TreeCacheTest#testListenerNonExistentRootLoop test
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
