If you can think of better doc, I'd appreciate it. On Oct 21, 2013, at 1:48 PM, Cameron McKenzie <[email protected]> wrote:
> hey Jordan, > I saw your JIRA update, thanks for looking into this. I'm just wondering if > the fix will work though? The test I attached to the JIRA ticket doesn't > actually call getCuratorListener() on a NamespaceFacade, it adds the listener > to the 'base' CuratorFramework instance, and the NamespaceFacade instance > just inherits it. > > Ultimately, maybe the easiest fix is to just update the documentation to > indicate that the paths for events passed to the CuratorListener instances > will be relative to the defined namespace of the 'base' CuratorFramework > instance? > > > On Mon, Oct 21, 2013 at 3:03 PM, Jordan Zimmerman > <[email protected]> wrote: > OK - I understand the problem now. I'm not sure how to fix it - I'll need to > think about this. > -JZ > > > On Oct 20, 2013, at 6:02 PM, Cameron McKenzie <[email protected]> wrote: > >> I don't think that that would fix things. It would just mean that no >> namespaces would be stripped off events (which may be acceptable, I'm not >> sure). >> >> I think that the problem currently is that there's a single Watcher instance >> that handles events across all CuratorFramework instances (the main one and >> any NamespaceFacade ones). >> >> That opens up a whole other can of worms though. If for some reason you had >> multiple NamespaceFacade instances at a given time (not sure why you'd want >> to do this, but I think that Curator would allow it), Given that your >> CuratorListener instances are bound to the 'main' CuratorFramework instance, >> you could get problems where the CuratorListener can't uniquely identify the >> zNode the event refers to. >> >> Imagine something like >> >> /namespace/bla >> /namespace/another/bla >> >> If I have two NamespaceFacade's one with a base of '/namespace' and another >> with '/namespace/another' then if the namespaces are stripped from the event >> paths, there's no way to distinguish between the two 'bla' zNodes. >> >> >> >> On Mon, Oct 21, 2013 at 11:50 AM, Jordan Zimmerman >> <[email protected]> wrote: >> As I recall, CuratorFrameworkFactory sets the namespace differently than >> when you call CuratorFramework.usingNamespace. I'd change the Factory to >> create the CuratorFramework and then call usingNamespace on the created >> instance so that they match. >> >> -JZ >> >> On Oct 20, 2013, at 5:47 PM, Cameron McKenzie <[email protected]> wrote: >> >>> TIcket is Curator-68 >>> >>> If you have a direction as to how you'd like to proceed with the fix, I can >>> probably help out if you like. >>> >>> cheers >>> Cam >>> >>> >>> On Mon, Oct 21, 2013 at 11:34 AM, Cameron McKenzie <[email protected]> >>> wrote: >>> I've had a bit more of a look into this and I think that the problem is in >>> the Watcher() implementation in the CuratorFrameworkImpl() constructor that >>> takes a Builder as an argument. When it processes a WatchedEvent it removes >>> the namespace from the event path >>> >>> unfixForNamespace(watchedEvent.getPath(); >>> >>> In the case where you've defined the namespace in the builder, this removes >>> the namespace prefix. In the case where you're using the NamespaceFacade, >>> the namespace of the CuratorFramework instance is null (because it wasn't >>> defined in the builder), so the namespace is not stripped off the event. >>> >>> I guess this is a bug, but I'm not sure what the correct fix is? The >>> easiest fix is to just not strip the namespace in both cases. To strip the >>> namespace in the NamespaceFacade case will be quite tricky I presume >>> because you've got a single Watcher interface handling potentially acting >>> as the backend for multiple NamespaceFacade instances. >>> >>> I'll add a ticket to Jira. >>> cheers >>> Cam >>> >>> >>> On Mon, Oct 21, 2013 at 11:01 AM, Cameron McKenzie <[email protected]> >>> wrote: >>> Will do, I'll double check I'm not doing something stupid first though. >>> cheers >>> >>> >>> On Mon, Oct 21, 2013 at 11:00 AM, Jordan Zimmerman >>> <[email protected]> wrote: >>> If I understand what you're saying that would be a bug. If you can, please >>> provide a test case and open an issue in Jira. >>> >>> -Jordan >>> >>> On Oct 20, 2013, at 4:52 PM, Cameron McKenzie <[email protected]> >>> wrote: >>> >>> > Not sure if I'm missing something, but it appears that there is a >>> > difference in functionality between defining a namespace during using the >>> > CuratorFrameworkFactory.builder().namespace("bla") method, and calling >>> > usingNamespace("bla") on an instance of the CuratorFramework itself. >>> > >>> > Both seem to create nodes correctly in ZooKeeper, but the paths for the >>> > events are inconsistent. If you using the Builder approach, the paths in >>> > the events do not include the namespace. If you use the CuratorFramework >>> > usingNamespace() approach, then the namespaces do appear in the event >>> > path. >>> > >>> > Is this by design? Or just a side effect? >>> > cheers >>> > Cam >>> > >>> > >>> >>> >>> >>> >> >> > >
