which reply you mentioned? Did you see my last mail? in the latest code, in the 'reset' method, the callback of the 'create' node, it will check if the state is 'CLOSED' and it will delete the created node if so by calling 'setNode(null)', Did I miss sth?
On Wed, Aug 7, 2013 at 4:01 AM, Jordan Zimmerman <[email protected] > wrote: > I replied on the thread. I believe the steps in the description can cause > the problem as described. > > -JZ > > > On Aug 3, 2013, at 6:06 AM, chao chu <[email protected]> wrote: > > 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 > > > -- ChuChao
