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 >>>>> > >>>>> > >>>>> >>>>> >>>> >>> >> >> > >
