curator-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cameron McKenzie <>
Subject Re: Curator namespaces
Date Mon, 21 Oct 2013 01:02:41 GMT
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

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


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

View raw message