Henry Robinson commented on ZOOKEEPER-460:
I need a little help getting to the bottom of this (I might be misreading
The code in question is, I think, 'ok' (although a bit dodgy). The idea is to
test the ability of a client - that is waiting because the max cnxns limit has
been reached - to reconnect once a slot becomes free on the server. So ideally
for this test close(1) should happen after createclient(2) has connected. As
you say, this is a false assumption as the close might happen before the
createClient(2) succeeds so there is no contention, but this should only be
giving false positives - the second assert should eventually succeed. What I
need to do to improve this is to replace createClient with a call that blocks
until we at least know the connection attempt has been made, if that's possible.
However the most recent Hudson failures don't seem to be related. From build
[exec] Zookeeper_simpleSystem::testAsyncWatcherAutoReset : assertion
[exec] Zookeeper_watchers::testDefaultSessionWatcher1 : OK
[exec] Zookeeper_watchers::testDefaultSessionWatcher2 : OK
[exec] Zookeeper_watchers::testObjectSessionWatcher1 : OK
[exec] Zookeeper_watchers::testObjectSessionWatcher2 : OK
[exec] Zookeeper_watchers::testNodeWatcher1 : OK
[exec] Zookeeper_watchers::testChildWatcher1 : OK
[exec] Zookeeper_watchers::testChildWatcher2 : OK
Assertion: equality assertion failed [Expected: -101, Actual : -4]
[exec] Failures !!!
[exec] Run: 32 Failure total: 1 Failures: 1 Errors: 0
[exec] make: *** [run-check] Error 1
and the same from 376 (yesterday's build). These are failing in TestClient
(specifically testAsyncWatcherAutoReset). The error here is that a stat
completion callback is getting called with ZCONNECTIONLOSS, but is expecting to
see ZNONODE, and the assert is failing.
This test runs fine for me locally, so is the problem a heavily loaded Hudson,
causing the connection loss?
Similarly the failed build you point to, 371, fails TestClientRetry with a
broken pipe error which to my novice eye sounds a bit like something falling
over under load.
It looks to me right now like the TestClientRetry code needs improving, but is
benign as it should only cause false positives, and we need to understand the
reasons why TestClient is failing. Does that sound right?
> bad testRetry in cppunit tests (hudson failure)
> Key: ZOOKEEPER-460
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-460
> Project: Zookeeper
> Issue Type: Bug
> Components: c client, tests
> Reporter: Patrick Hunt
> Assignee: Henry Robinson
> Fix For: 3.2.1, 3.3.0
> the followng code failed on hudson
> watchctx_t ctx1, ctx2;
> zhandle_t *zk1 = createClient(&ctx1);
> CPPUNIT_ASSERT_EQUAL(true, ctx1.waitForConnected(zk1));
> zhandle_t *zk2 = createClient(&ctx2);
> CPPUNIT_ASSERT_EQUAL(true, ctx2.waitForConnected(zk2));
> there's a problem with this test, it assumes that close(1) can be called
> before createclient(2) gets connected.
> this is not correct: createclient is an async call an in some cases the
> connection can be established before
> create client returns.
> this shows a failure in this case because client1 was created, then client2
> attempted to connect
> but failed due to this on the server (max conn exceeded):
> sprintf(cmd, "export ZKMAXCNXNS=1;%s startClean %s", ZKSERVER_CMD,
> conn 2 failed and therefore the following assert eventually failed.
> this code should not assume that close(1) will beat connect(2)
> Henry can you take a look?
This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.