Mailing-List: contact dev-help@curator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@curator.apache.org
Date: Wed, 24 Jun 2015 23:09:04 +0000 (UTC)
From: "Mike Drob (JIRA)" <jira@apache.org>
To: dev@curator.apache.org
Message-ID: <JIRA.12829152.1431426290000.8277.1435187344595@Atlassian.JIRA>
In-Reply-To: <JIRA.12829152.1431426290000@Atlassian.JIRA>
References: <JIRA.12829152.1431426290000@Atlassian.JIRA>
 <JIRA.12829152.1431426290934@arcas>
Subject: [jira] [Commented] (CURATOR-218) TreeCache initialization problem
 with non existant root path
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/CURATOR-218?page=3Dcom.atlassia=
n.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D146=
00340#comment-14600340 ]=20

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 =3D 0 ; i < 50 ; i++)
        {
            client =3D CuratorFrameworkFactory.newClient(server.getConnectS=
tring(), new RetryOneTime(100));
            try=20
            {
                client.start();
                client.blockUntilConnected();
               =20
                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 log=
s from the test run -

{noformat}
java.lang.AssertionError: Not connected after blocking for connection #3 ex=
pected [true] but found [false]
=09at org.testng.Assert.fail(Assert.java:94)
=09at org.testng.Assert.failNotEquals(Assert.java:494)
=09at org.testng.Assert.assertTrue(Assert.java:42)
=09at org.apache.curator.framework.imps.TestBlockUntilConnected.testBlockUn=
tilConnectedTightLoop(TestBlockUntilConnected.java:251)


INFO  org.apache.curator.framework.imps.CuratorFrameworkImpl  Starting [mai=
n]
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 chan=
ge: 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 _n=
ot_ be connected... no connection loss, no session loss, nothing...

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

Anyway, the TreeCache never sees that INITIALIZED event as the issue report=
ed 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 =3D 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 =3D=20
> Distributor ID:=09Ubuntu
> Description:=09Ubuntu 14.04.1 LTS
> Release:=0914.04
> Codename:=09trusty
> ZK version: is a curator TestingServer
> java: java 8
> maven: 3.2.5
>            Reporter: Samuel Garc=C3=ADa Mart=C3=ADnez
>            Assignee: Scott Blum
>         Attachments: failing_test.txt
>
>
> I'm implementing a Guava service relying on the startAsync feature. I'm u=
sing 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 t=
est to force it).
> repo with tests: https://github.com/samuelgmartinez/curator-treecache-tes=
ts.git
> failing test: mvn -Dtest=3DTreeCacheTest#testListenerNonExistentRootLoop =
test


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)