curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cameron McKenzie <mckenzie....@gmail.com>
Subject Re: CURATOR-3.0 tests
Date Thu, 02 Jun 2016 00:37:49 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message