I replied in the Jira comments. I'd like to keep the comments there so there's a nice thread/record of it.
-Jordan On Aug 6, 2013, at 4:39 PM, chao chu <[email protected]> wrote: > 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
