curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott Blum <dragonsi...@gmail.com>
Subject Re: CURATOR-3.0 tests
Date Wed, 25 May 2016 16:06:45 GMT
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