curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jordan Zimmerman <jor...@jordanzimmerman.com>
Subject Re: CURATOR-3.0 tests
Date Thu, 02 Jun 2016 01:15:40 GMT
Can you push your unit test somewhere?

> On Jun 1, 2016, at 7:37 PM, Cameron McKenzie <mckenzie.cam@gmail.com> wrote:
> 
> Indeed. There seems to be a problem with InterProcessSemaphoreV2 though.
> I've written a simplified unit test that just has a bunch of clients
> attempting to grab a lease on the semaphore. When I shutdown and restart ZK
> about 25% of the time, none of the clients can reacquire the semaphore.
> 
> Still trying to work out what's going on, but I'm probably not going to
> have a lot of time today to look at it.
> cheers
> 
> On Thu, Jun 2, 2016 at 10:30 AM, Jordan Zimmerman <
> jordan@jordanzimmerman.com> wrote:
> 
>> Odd - SemaphoreClient does seem wrong.
>> 
>>> On Jun 1, 2016, at 1:43 AM, Cameron McKenzie <mckenzie.cam@gmail.com>
>> wrote:
>>> 
>>> It looks like under some circumstances (which I haven't worked out yet)
>>> that the InterprocessMutex acquire() is not working correctly when
>>> reconnecting to ZK. Still digging into why this is.
>>> 
>>> There also seems to be a bug in the SemaphoreClient, unless I'm missing
>>> something. At lines 126 and 140 it does compareAndSet() calls but throws
>> an
>>> exception if they return true. As far as I can work out, this means that
>>> whenever the lock is acquired, an exception gets thrown indicating that
>>> there are Multiple acquirers.
>>> 
>>> This test is failing fairly consistently. It seems to be the remaining
>> test
>>> that keeps failing in the Jenkins build also
>>> cheers
>>> 
>>> 
>>> On Wed, Jun 1, 2016 at 3:10 PM, Cameron McKenzie <mckenzie.cam@gmail.com
>>> 
>>> wrote:
>>> 
>>>> Looks like I was incorrect. The NoWatcherException is being thrown on
>>>> success as well, and the problem is not in the cluster restart. Will
>> keep
>>>> digging.
>>>> 
>>>> On Wed, Jun 1, 2016 at 2:52 PM, Cameron McKenzie <
>> mckenzie.cam@gmail.com>
>>>> wrote:
>>>> 
>>>>> TestInterProcessSemaphoreCluster.testCluster() is failling (assertion
>> at
>>>>> line 294). Again, it seems like some sort of race condition with the
>>>>> watcher removal.
>>>>> 
>>>>> When I run it in Eclipse, it fails maybe 25% of the time. When it fails
>>>>> it seems that it's got something to do with watcher removal. When the
>> test
>>>>> passes, this error is not logged.
>>>>> 
>>>>> org.apache.zookeeper.KeeperException$NoWatcherException:
>> KeeperErrorCode
>>>>> = No such watcher for /foo/bar/lock/leases
>>>>> at
>>>>> 
>> org.apache.zookeeper.ZooKeeper$ZKWatchManager.containsWatcher(ZooKeeper.java:377)
>>>>> at
>>>>> 
>> org.apache.zookeeper.ZooKeeper$ZKWatchManager.removeWatcher(ZooKeeper.java:252)
>>>>> at
>>>>> 
>> org.apache.zookeeper.WatchDeregistration.unregister(WatchDeregistration.java:58)
>>>>> at org.apache.zookeeper.ClientCnxn.finishPacket(ClientCnxn.java:712)
>>>>> at org.apache.zookeeper.ClientCnxn.access$1500(ClientCnxn.java:97)
>>>>> at
>>>>> 
>> org.apache.zookeeper.ClientCnxn$SendThread.readResponse(ClientCnxn.java:948)
>>>>> at
>>>>> 
>> org.apache.zookeeper.ClientCnxnSocketNIO.doIO(ClientCnxnSocketNIO.java:99)
>>>>> at
>>>>> 
>> org.apache.zookeeper.ClientCnxnSocketNIO.doTransport(ClientCnxnSocketNIO.java:361)
>>>>> at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1236)
>>>>> 
>>>>> Is it possible it's something to do with the way that the cluster is
>>>>> restarted at line 282? The old cluster is not shutdown, a new one is
>> just
>>>>> created.
>>>>> 
>>>>> 
>>>>> On Wed, Jun 1, 2016 at 10:44 AM, Jordan Zimmerman <
>>>>> jordan@jordanzimmerman.com> wrote:
>>>>> 
>>>>>> I’ll try to address this as part of CURATOR-333
>>>>>> 
>>>>>>> On May 31, 2016, at 7:08 PM, Cameron McKenzie <
>> mckenzie.cam@gmail.com>
>>>>>> wrote:
>>>>>>> 
>>>>>>> Maybe we need to look at some way of providing a hook for tests
to
>> wait
>>>>>>> reliably for asynch tasks to finish?
>>>>>>> 
>>>>>>> The latest round of tests ran OK. One test failed on an unrelated
>> thing
>>>>>>> (ConnectionLoss), but this appears to be a transient thing as
it's
>>>>>> worked
>>>>>>> ok the next time around.
>>>>>>> 
>>>>>>> I will start getting a release together. Thanks for you help
with the
>>>>>>> updated tests.
>>>>>>> cheers
>>>>>>> 
>>>>>>> On Wed, Jun 1, 2016 at 9:12 AM, Jordan Zimmerman <
>>>>>> jordan@jordanzimmerman.com
>>>>>>>> wrote:
>>>>>>> 
>>>>>>>> The problem is in-flight watchers and async background calls.
>> There’s
>>>>>> no
>>>>>>>> way to cancel these and they can take time to occur - even
after a
>>>>>> recipe
>>>>>>>> instance is closed.
>>>>>>>> 
>>>>>>>> -Jordan
>>>>>>>> 
>>>>>>>>> On May 31, 2016, at 5:11 PM, Cameron McKenzie <
>>>>>> mckenzie.cam@gmail.com>
>>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>> Ok, running it again now.
>>>>>>>>> 
>>>>>>>>> Is the problem that the watcher clean up for the recipes
is done
>>>>>>>>> asynchronously after they are closed?
>>>>>>>>> 
>>>>>>>>> On Wed, Jun 1, 2016 at 1:35 AM, Jordan Zimmerman <
>>>>>>>> jordan@jordanzimmerman.com
>>>>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>>> OK - please try now. I added a loop in the “no
watchers” checker.
>> If
>>>>>>>> there
>>>>>>>>>> are remaining watchers, it will sleep a bit and try
again.
>>>>>>>>>> 
>>>>>>>>>> -Jordan
>>>>>>>>>> 
>>>>>>>>>>> On May 31, 2016, at 1:33 AM, Cameron McKenzie
<
>>>>>> mckenzie.cam@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>> 
>>>>>>>>>>> Looks like these failures are intermittent. Running
them directly
>>>>>> in
>>>>>>>>>>> Eclipse they seem to be passing. I will run the
whole thing again
>>>>>> in
>>>>>>>> the
>>>>>>>>>>> morning and see how it goes.
>>>>>>>>>>> 
>>>>>>>>>>> On Tue, May 31, 2016 at 2:29 PM, Cameron McKenzie
<
>>>>>>>>>> mckenzie.cam@gmail.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>> 
>>>>>>>>>>>> There are still 2 tests failing for me:
>>>>>>>>>>>> 
>>>>>>>>>>>> FAILURE! - in
>>>>>>>>>>>> org.apache.curator.framework.recipes.cache.TestPathChildrenCache
>>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>> 
>>>>>> 
>> testKilledSession(org.apache.curator.framework.recipes.cache.TestPathChildrenCache)
>>>>>>>>>>>> Time elapsed: 17.488 sec  <<< FAILURE!
>>>>>>>>>>>> java.lang.AssertionError: One or more child
watchers are still
>>>>>>>>>> registered:
>>>>>>>>>>>> [/test]
>>>>>>>>>>>> at
>>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>> 
>>>>>> 
>> org.apache.curator.framework.imps.TestCleanState.closeAndTestClean(TestCleanState.java:53)
>>>>>>>>>>>> at
>>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>> 
>>>>>> 
>> org.apache.curator.framework.recipes.cache.TestPathChildrenCache.testKilledSession(TestPathChildrenCache.java:707)
>>>>>>>>>>>> 
>>>>>>>>>>>> FAILURE! - in
>>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>> 
>>>>>> 
>> org.apache.curator.framework.recipes.locks.TestInterProcessSemaphoreCluster
>>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>> 
>>>>>> 
>> testCluster(org.apache.curator.framework.recipes.locks.TestInterProcessSemaphoreCluster)
>>>>>>>>>>>> Time elapsed: 96.641 sec  <<< FAILURE!
>>>>>>>>>>>> java.lang.AssertionError: 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.testng.Assert.assertTrue(Assert.java:52)
>>>>>>>>>>>> at
>>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>> 
>>>>>> 
>> org.apache.curator.framework.recipes.locks.TestInterProcessSemaphoreCluster.testCluster(TestInterProcessSemaphoreCluster.java:294)
>>>>>>>>>>>> 
>>>>>>>>>>>> Failed tests:
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>> 
>>>>>> 
>> org.apache.curator.framework.recipes.cache.TestPathChildrenCache.testKilledSession(org.apache.curator.framework.recipes.cache.TestPathChildrenCache)
>>>>>>>>>>>> Run 1: TestPathChildrenCache.testKilledSession:707
One or more
>>>>>> child
>>>>>>>>>>>> watchers are still registered: [/test]
>>>>>>>>>>>> Run 2: PASS
>>>>>>>>>>>> 
>>>>>>>>>>>> TestInterProcessSemaphoreCluster.testCluster:294
expected [true]
>>>>>> but
>>>>>>>>>>>> found [false]
>>>>>>>>>>>> 
>>>>>>>>>>>> Tests run: 495, Failures: 2, Errors: 0, Skipped:
0
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> On Tue, May 31, 2016 at 12:52 PM, Cameron
McKenzie <
>>>>>>>>>> mckenzie.cam@gmail.com
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>>> Thanks, CURATOR-332 wasn't pushed. I
will run the tests against
>>>>>> that,
>>>>>>>>>> and
>>>>>>>>>>>>> if it's all good will merge into CURATOR-3.0
>>>>>>>>>>>>> cheers
>>>>>>>>>>>>> 
>>>>>>>>>>>>> On Tue, May 31, 2016 at 12:32 PM, Jordan
Zimmerman <
>>>>>>>>>>>>> jordan@jordanzimmerman.com> wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Actually - I don’t remember if
branch CURATOR-332 is merged
>>>>>> yet. I
>>>>>>>>>>>>>> made/pushed my changes in CURATOR-332
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> -jordan
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> On May 26, 2016, at 10:04 PM,
Cameron McKenzie <
>>>>>>>>>> mckenzie.cam@gmail.com>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> I'm still seeing 6 failed tests
that seem related to the same
>>>>>> stuff
>>>>>>>>>>>>>> after
>>>>>>>>>>>>>>> merging your fix:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Failed tests:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>> 
>>>>>> 
>> org.apache.curator.framework.recipes.cache.TestPathChildrenCache.testBasics(org.apache.curator.framework.recipes.cache.TestPathChildrenCache)
>>>>>>>>>>>>>>> Run 1: TestPathChildrenCache.testBasics:863
One or more child
>>>>>>>>>> watchers
>>>>>>>>>>>>>>> are still registered: [/test]
>>>>>>>>>>>>>>> Run 2: TestPathChildrenCache.testBasics:863
One or more child
>>>>>>>>>> watchers
>>>>>>>>>>>>>>> are still registered: [/test]
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>> 
>>>>>> 
>> org.apache.curator.framework.recipes.cache.TestPathChildrenCache.testBasicsOnTwoCachesWithSameExecutor(org.apache.curator.framework.recipes.cache.TestPathChildrenCache)
>>>>>>>>>>>>>>> Run 1:
>>>>>>>>>> TestPathChildrenCache.testBasicsOnTwoCachesWithSameExecutor:934
>>>>>>>>>>>>>>> One or more child watchers are
still registered: [/test]
>>>>>>>>>>>>>>> Run 2:
>>>>>>>>>> TestPathChildrenCache.testBasicsOnTwoCachesWithSameExecutor:934
>>>>>>>>>>>>>>> One or more child watchers are
still registered: [/test]
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>> 
>>>>>> 
>> org.apache.curator.framework.recipes.cache.TestPathChildrenCache.testEnsurePath(org.apache.curator.framework.recipes.cache.TestPathChildrenCache)
>>>>>>>>>>>>>>> Run 1: TestPathChildrenCache.testEnsurePath:363
One or more
>>>>>> child
>>>>>>>>>>>>>>> watchers are still registered:
[/one/two/three]
>>>>>>>>>>>>>>> Run 2: TestPathChildrenCache.testEnsurePath:363
One or more
>>>>>> child
>>>>>>>>>>>>>>> watchers are still registered:
[/one/two/three]
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> TestInterProcessSemaphoreCluster.testCluster:294
expected
>>>>>> [true]
>>>>>>>> but
>>>>>>>>>>>>>>> found [false]
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>> 
>>>>>> 
>> org.apache.curator.framework.recipes.shared.TestSharedCount.testMultiClientVersioned(org.apache.curator.framework.recipes.shared.TestSharedCount)
>>>>>>>>>>>>>>> Run 1: PASS
>>>>>>>>>>>>>>> Run 2: TestSharedCount.testMultiClientVersioned:256
One or
>> more
>>>>>>>> data
>>>>>>>>>>>>>>> watchers are still registered:
[/count]
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>> 
>>>>>> 
>> org.apache.curator.framework.recipes.shared.TestSharedCount.testSimple(org.apache.curator.framework.recipes.shared.TestSharedCount)
>>>>>>>>>>>>>>> Run 1: TestSharedCount.testSimple:174
One or more data
>>>>>> watchers are
>>>>>>>>>>>>>> still
>>>>>>>>>>>>>>> registered: [/count]
>>>>>>>>>>>>>>> Run 2: TestSharedCount.testSimple:174
One or more data
>>>>>> watchers are
>>>>>>>>>>>>>> still
>>>>>>>>>>>>>>> registered: [/count]
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Tests run: 491, Failures: 6,
Errors: 0, Skipped: 0
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> On Fri, May 27, 2016 at 3:30
AM, Jordan Zimmerman <
>>>>>>>>>>>>>>> jordan@jordanzimmerman.com>
wrote:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> I see the problem. The fix
is not simple though so I’ll
>> spend
>>>>>> some
>>>>>>>>>>>>>> time on
>>>>>>>>>>>>>>>> it. The TL;DR is that exists
watchers are still supposed to
>>>>>> get
>>>>>>>> set
>>>>>>>>>>>>>> when
>>>>>>>>>>>>>>>> there is a KeeperException.NoNode
and the code isn’t
>> handling
>>>>>> it.
>>>>>>>>>> But,
>>>>>>>>>>>>>>>> while I was looking at the
code I realized there are some
>>>>>>>>>> significant
>>>>>>>>>>>>>>>> additional problems. Curator,
here, is trying to mirror what
>>>>>>>>>>>>>> ZooKeeper does
>>>>>>>>>>>>>>>> internally which is insanely
complicated. In hindsight, the
>>>>>> whole
>>>>>>>> ZK
>>>>>>>>>>>>>>>> watcher mechanism should’ve
been decoupled from the mutator
>>>>>> APIs.
>>>>>>>>>>>>>> But, of
>>>>>>>>>>>>>>>> course, that’s easy for
me to say now.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> -Jordan
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> On May 26, 2016, at 1:10
AM, Cameron McKenzie <
>>>>>>>>>>>>>> mckenzie.cam@gmail.com>
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> Thanks Scott,
>>>>>>>>>>>>>>>>> Those tests are now passing
for me.
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> Jordan, testNodeCache:testBasics()
is failing consistently
>>>>>> on the
>>>>>>>>>> 3.0
>>>>>>>>>>>>>>>>> branch. It appears that
this is actually potentially a bug
>>>>>> in the
>>>>>>>>>>>>>>>>> NodeCache. It ends up
leaking a Watcher reference. I've
>> had a
>>>>>>>> quick
>>>>>>>>>>>>>> look
>>>>>>>>>>>>>>>>> through, but I haven't
dived in in any detail. It's the
>>>>>>>>>>>>>>>>> WatcherRemovalManager
stuff I think. If you've got time,
>> can
>>>>>> you
>>>>>>>>>>>>>> have a
>>>>>>>>>>>>>>>>> look? If not, let me
know and I'll do some more digging.
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> cheers
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> On Thu, May 26, 2016
at 11:47 AM, Cameron McKenzie <
>>>>>>>>>>>>>>>> mckenzie.cam@gmail.com>
>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> Thanks Scott.
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> Push the fix to master
and merge it into 3.0.
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> Then I guess, I'll
push new versions of 2.11 and 3.2 onto
>>>>>> Nexus.
>>>>>>>>>>>>>>>>>> cheers
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> On Thu, May 26, 2016
at 11:44 AM, Scott Blum <
>>>>>>>>>> dragonsinth@gmail.com
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> Alright, I have
a fix, but it wants to be applied to both
>>>>>>>> master
>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>> 3.0.
>>>>>>>>>>>>>>>>>>> Where should
I push the fix?
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> On Wed, May 25,
2016 at 6:10 PM, Cameron McKenzie <
>>>>>>>>>>>>>>>> mckenzie.cam@gmail.com
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> Thanks Scott,
>>>>>>>>>>>>>>>>>>>> If you just
checkout the CURATOR-3.0 branch, they are
>>>>>> failing
>>>>>>>>>>>>>> there.
>>>>>>>>>>>>>>>>>>>> cheers
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> On Thu, May
26, 2016 at 2:06 AM, Scott Blum <
>>>>>>>>>>>>>> dragonsinth@gmail.com>
>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> Sure,
what SHA are they failing at Cam?
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> On Wed,
May 25, 2016 at 9:36 AM, Jordan Zimmerman <
>>>>>>>>>>>>>>>>>>>>> jordan@jordanzimmerman.com>
wrote:
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> Scott
can you take a look?
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> -Jordan
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>
On May 25, 2016, at 4:35 AM, Cameron McKenzie <
>>>>>>>>>>>>>>>>>>>> mckenzie.cam@gmail.com>
>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>

>>>>>>>>>>>>>>>>>>>>>>>
Tree cache tests are still failing. I've tried a few
>>>>>> times
>>>>>>>>>> but
>>>>>>>>>>>>>> no
>>>>>>>>>>>>>>>>>>>> love:
>>>>>>>>>>>>>>>>>>>>>>>

>>>>>>>>>>>>>>>>>>>>>>>

>>>>>>>>>>>>>> 
>>>>>> TestTreeCacheEventOrdering>TestEventOrdering.testEventOrdering:151
>>>>>>>>>>>>>>>>>>>>>> actual
6
>>>>>>>>>>>>>>>>>>>>>>>
expected -31:
>>>>>>>>>>>>>>>>>>>>>>>

>>>>>>>>>>>>>>>>>>>>>>>
I will have a look into what's going on in the
>> morning.
>>>>>>>> Given
>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>> these
>>>>>>>>>>>>>>>>>>>>>>>
may take some messing about to fix up, do we just
>> want
>>>>>> to
>>>>>>>>>> vote
>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>>>>>>>> 2.11.0
>>>>>>>>>>>>>>>>>>>>>>>
separately, as that is all ready to go?
>>>>>>>>>>>>>>>>>>>>>>>
cheers
>>>>>>>>>>>>>>>>>>>>>>>

>>>>>>>>>>>>>>>>>>>>>>>
On Wed, May 25, 2016 at 5:34 PM, Jordan Zimmerman <
>>>>>>>>>>>>>>>>>>>>>>>
jordan@jordanzimmerman.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>

>>>>>>>>>>>>>>>>>>>>>>>>
Great news. Thanks.
>>>>>>>>>>>>>>>>>>>>>>>>

>>>>>>>>>>>>>>>>>>>>>>>>
====================
>>>>>>>>>>>>>>>>>>>>>>>>
Jordan Zimmerman
>>>>>>>>>>>>>>>>>>>>>>>>

>>>>>>>>>>>>>>>>>>>>>>>>>
On May 25, 2016, at 12:37 AM, Cameron McKenzie <
>>>>>>>>>>>>>>>>>>>>> mckenzie.cam@gmail.com
>>>>>>>>>>>>>>>>>>>>>>>

>>>>>>>>>>>>>>>>>>>>>>>>
wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>

>>>>>>>>>>>>>>>>>>>>>>>>>
I have fixed up the test case, all good now.
>>>>>>>>>>>>>>>>>>>>>>>>>

>>>>>>>>>>>>>>>>>>>>>>>>>
On Wed, May 25, 2016 at 1:45 PM, Cameron McKenzie <
>>>>>>>>>>>>>>>>>>>>>>>>
mckenzie.cam@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>
wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>

>>>>>>>>>>>>>>>>>>>>>>>>>>
Looks like it was introduced with the schema
>>>>>> validation
>>>>>>>>>>>>>> stuff.
>>>>>>>>>>>>>>>>>>> It
>>>>>>>>>>>>>>>>>>>>> now
>>>>>>>>>>>>>>>>>>>>>>>>
does
>>>>>>>>>>>>>>>>>>>>>>>>>>
an ACL check prior to the backgrounding call.
>>>>>> Because
>>>>>>>> the
>>>>>>>>>>>>>> unit
>>>>>>>>>>>>>>>>>>>> test
>>>>>>>>>>>>>>>>>>>>>>>>
uses a
>>>>>>>>>>>>>>>>>>>>>>>>>>
bogus ACL provider it just throws an exception
>>>>>>>>>>>>>>>>>>>>>>>>>>

>>>>>>>>>>>>>>>>>>>>>>>>>>
final String adjustedPath =
>>>>>>>>>>>>>>>>>>>>>>>>>>
adjustPath(client.fixForNamespace(givenPath,
>>>>>>>>>>>>>>>>>>>>>>>>
createMode.isSequential()));
>>>>>>>>>>>>>>>>>>>>>>>>>>
List<ACL> aclList =
>>>>>> acling.getAclList(adjustedPath);
>>>>>>>>>>>>>>>>>>>>>>>>>>

>>>>>>>>>>>>>>>>>>>>>>>>>>

>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>> 
>> client.getSchemaSet().getSchema(givenPath).validateCreate(createMode,
>>>>>>>>>>>>>>>>>>>>>>>>
data,
>>>>>>>>>>>>>>>>>>>>>>>>>>
aclList);
>>>>>>>>>>>>>>>>>>>>>>>>>>

>>>>>>>>>>>>>>>>>>>>>>>>>>
String returnPath = null;
>>>>>>>>>>>>>>>>>>>>>>>>>>
if ( backgrounding.inBackground() )
>>>>>>>>>>>>>>>>>>>>>>>>>>
{
>>>>>>>>>>>>>>>>>>>>>>>>>>
   pathInBackground(adjustedPath, data,
>>>>>> givenPath);
>>>>>>>>>>>>>>>>>>>>>>>>>>

>>>>>>>>>>>>>>>>>>>>>>>>>>
So, I guess the answer is to get the test to
>> force a
>>>>>>>>>> failure
>>>>>>>>>>>>>>>>>>> in a
>>>>>>>>>>>>>>>>>>>>>>>>>>
different way. With the UnhandledErrorListener,
>> the
>>>>>>>>>>>>>>>>>>> expectation is
>>>>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>>>>>>>
this only gets called on backgrounding operations?
>>>>>>>>>>>>>>>>>>>>>>>>>>
cheers
>>>>>>>>>>>>>>>>>>>>>>>>>>

>>>>>>>>>>>>>>>>>>>>>>>>>>
On Wed, May 25, 2016 at 1:39 PM, Cameron McKenzie
>> <
>>>>>>>>>>>>>>>>>>>>>>>>
mckenzie.cam@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>
wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>

>>>>>>>>>>>>>>>>>>>>>>>>>>>
Same on the master branch, but it passes there,
>> so
>>>>>>>> maybe
>>>>>>>>>>>>>>>>>>>> something
>>>>>>>>>>>>>>>>>>>>>> has
>>>>>>>>>>>>>>>>>>>>>>>>>>>
legitimately broken the test. Will let you know
>> if
>>>>>> I
>>>>>>>> get
>>>>>>>>>>>>>>>>>>> stuck.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
cheers
>>>>>>>>>>>>>>>>>>>>>>>>>>>

>>>>>>>>>>>>>>>>>>>>>>>>>>>
On Wed, May 25, 2016 at 1:36 PM, Jordan
>> Zimmerman <
>>>>>>>>>>>>>>>>>>>>>>>>>>>
jordan@jordanzimmerman.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>

>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Let me know if you need help.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>

>>>>>>>>>>>>>>>>>>>>>>>>>>>>
It might be a bad merge. Have you compared it to
>>>>>> the
>>>>>>>>>>>>>> master
>>>>>>>>>>>>>>>>>>>>> branch?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>

>>>>>>>>>>>>>>>>>>>>>>>>>>>>
-JZ
>>>>>>>>>>>>>>>>>>>>>>>>>>>>

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
On May 24, 2016, at 10:31 PM, Cameron
>> McKenzie <
>>>>>>>>>>>>>>>>>>>>>>>>
mckenzie.cam@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Guys,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
There's a test
>>>>>>>>>> TestFrameworkBackground:testErrorListener
>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
failing
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
consistently on the CURATOR-3.0 branch.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
I can't see how it has ever worked. It seems to
>>>>>> try
>>>>>>>> and
>>>>>>>>>>>>>>>>>>> provoke
>>>>>>>>>>>>>>>>>>>>> an
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
error
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
via a bad ACL provider.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
But this ACL provider is called by the
>>>>>>>>>> CreateBuilderImpl
>>>>>>>>>>>>>>>>>>> prior
>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
backgrounding call, which means that the
>>>>>> exception
>>>>>>>> that
>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>>>>> throws
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
happens
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
in the main Thread of the unit test. So, it
>> just
>>>>>>>> throws
>>>>>>>>>>>>>> an
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
UnsupportedOperationException which is
>>>>>> propogated up
>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> stack
>>>>>>>>>>>>>>>>>>>> at
>>>>>>>>>>>>>>>>>>>>>>>>
which
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
point the unit test fails.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
So, I will look at fixing this, but I just
>> don't
>>>>>>>>>>>>>> understand
>>>>>>>>>>>>>>>>>>> how
>>>>>>>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>>>>>>>>>
ever
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
worked?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
cheers
>>>>>>>>>>>>>>>>>>>>>>>>>>

>>>>>>>>>>>>>>>>>>>>>>>>

>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>> 
>> 


Mime
View raw message