By checking the code again, I thought the issue mentioned in the
description of CURATOR-3 should have already been fixed.
in the callback of the 'create' node operation in 'reset':
if ( event.getResultCode() ==
KeeperException.Code.OK.intValue() )
{
setNode(event.getName());
* if ( state.get() == State.CLOSED )*
* {*
* setNode(null);*
* }*
else
{
getChildren();
}
}
else
{
log.error("getChildren() failed. rc = " +
event.getResultCode());
}
on creating the node successfully, in that callback, it will check the
state again and if it's already 'CLOSED', it will call setNode(null), thus
the node will be created. The earlier code doesn't have this check, I
checked the latest version (1.3.4) back to the netflix age, the code is
like below:
if ( event.getResultCode() ==
KeeperException.Code.OK.intValue() )
{
setNode(event.getName());
getChildren();
}
Could you please take a look at this and maybe you can close the issue if
it's the case. Thanks
On Sat, Aug 3, 2013 at 1:23 AM, Jordan Zimmerman <[email protected]
> wrote:
> How do you plan to address this? It seems infinitely recursive ;)
>
> -JZ
>
>
> On Aug 2, 2013, at 7:42 AM, chao chu <[email protected]> wrote:
>
> Ok, thanks for all your replies. I will try to see if I can re-produce and
> fix the issue https://issues.apache.org/jira/browse/CURATOR-3 then.
>
> Cheers,
>
>
> On Fri, Aug 2, 2013 at 9:35 PM, Michael Morello <[email protected]
> > wrote:
>
>> Both have a high priority (at least in JIRA), let's go for
>> https://issues.apache.org/jira/browse/CURATOR-45
>>
>>
>> 2013/8/1 Luciano Resende <[email protected]>
>>
>>>
>>> On Thu, Aug 1, 2013 at 12:44 PM, Michael Morello <
>>> [email protected]> wrote:
>>>
>>>> I volunteer to (try to) help on one of these two problems, Jordan,
>>>> which one is best suited for a first contribution ?
>>>>
>>>>
>>> Whichever you feel comfortable with. But one could assume the highest
>>> priority one would be the most complex.
>>>
>>
>>
>>
>
>
> --
> ChuChao
>
>
>
--
ChuChao
