Mailing-List: contact dev-help@curator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@curator.apache.org
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Subject: Re: CURATOR-3.0 tests
From: Jordan Zimmerman <jordan@jordanzimmerman.com>
In-Reply-To: <CANykdua5oyFT2duPoS=MFR_EnSuxvtp0kL3OQHFJV7ufag03ag@mail.gmail.com>
Date: Wed, 25 May 2016 08:36:30 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <18A7FA8A-6D57-4861-9740-7DFE5DBF8065@jordanzimmerman.com>
References: <CANykduZ_8vgz5wp19_am_G7s-CFk7_gN-D0z2Dt1NdxQ5Pjs+g@mail.gmail.com> <F65C2749-6585-4188-A2AF-C448AADE7B59@jordanzimmerman.com> <CANykduYbUtRzrVEGLzBeMmvkNuSvSRrqgEZy5TOaKT9gQEat_Q@mail.gmail.com> <CANykduYtnkom1CePvuMA30K0FPaAJmcC65R4ep7=-nc=vy0Dzg@mail.gmail.com> <CANykdubO+0xGNyjTbYWaRgR6ZRb3E7Y11VNMXBZ98NbZXQRCng@mail.gmail.com> <9BFB70F4-3965-4711-8838-B9CBC33F1BD0@jordanzimmerman.com> <CANykdua5oyFT2duPoS=MFR_EnSuxvtp0kL3OQHFJV7ufag03ag@mail.gmail.com>
To: dev@curator.apache.org,
 Scott Blum <dragonsinth@gmail.com>
archived-at: Wed, 25 May 2016 13:54:36 -0000

Scott can you take a look?

-Jordan

> On May 25, 2016, at 4:35 AM, Cameron McKenzie <mckenzie.cam@gmail.com> =
wrote:
>=20
> Tree cache tests are still failing. I've tried a few times but no =
love:
>=20
> TestTreeCacheEventOrdering>TestEventOrdering.testEventOrdering:151 =
actual 6
> expected -31:
>=20
> 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
>=20
> On Wed, May 25, 2016 at 5:34 PM, Jordan Zimmerman <
> jordan@jordanzimmerman.com> wrote:
>=20
>> Great news. Thanks.
>>=20
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> Jordan Zimmerman
>>=20
>>> On May 25, 2016, at 12:37 AM, Cameron McKenzie =
<mckenzie.cam@gmail.com>
>> wrote:
>>>=20
>>> I have fixed up the test case, all good now.
>>>=20
>>> On Wed, May 25, 2016 at 1:45 PM, Cameron McKenzie <
>> mckenzie.cam@gmail.com>
>>> wrote:
>>>=20
>>>> 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
>>>>=20
>>>>       final String adjustedPath =3D
>>>> adjustPath(client.fixForNamespace(givenPath,
>> createMode.isSequential()));
>>>>       List<ACL> aclList =3D acling.getAclList(adjustedPath);
>>>>=20
>>>> =
client.getSchemaSet().getSchema(givenPath).validateCreate(createMode,
>> data,
>>>> aclList);
>>>>=20
>>>>       String returnPath =3D null;
>>>>       if ( backgrounding.inBackground() )
>>>>       {
>>>>           pathInBackground(adjustedPath, data, givenPath);
>>>>=20
>>>> 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
>>>>=20
>>>> On Wed, May 25, 2016 at 1:39 PM, Cameron McKenzie <
>> mckenzie.cam@gmail.com>
>>>> wrote:
>>>>=20
>>>>> 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
>>>>>=20
>>>>> On Wed, May 25, 2016 at 1:36 PM, Jordan Zimmerman <
>>>>> jordan@jordanzimmerman.com> wrote:
>>>>>=20
>>>>>> Let me know if you need help.
>>>>>>=20
>>>>>> It might be a bad merge. Have you compared it to the master =
branch?
>>>>>>=20
>>>>>> -JZ
>>>>>>=20
>>>>>>>> On May 24, 2016, at 10:31 PM, Cameron McKenzie <
>> mckenzie.cam@gmail.com>
>>>>>>> wrote:
>>>>>>>=20
>>>>>>> Guys,
>>>>>>> There's a test TestFrameworkBackground:testErrorListener that is
>>>>>> failing
>>>>>>> consistently on the CURATOR-3.0 branch.
>>>>>>>=20
>>>>>>> I can't see how it has ever worked. It seems to try and provoke =
an
>>>>>> error
>>>>>>> via a bad ACL provider.
>>>>>>>=20
>>>>>>> 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.
>>>>>>>=20
>>>>>>> So, I will look at fixing this, but I just don't understand how =
it
>> ever
>>>>>>> worked?
>>>>>>> cheers
>>>>=20
>>=20