curator-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cameron McKenzie <mckenzie....@gmail.com>
Subject Re: Curator namespaces
Date Mon, 21 Oct 2013 20:48:18 GMT
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 <
jordan@jordanzimmerman.com> 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 <mckenzie.cam@gmail.com>
> 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 <
> jordan@jordanzimmerman.com> 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 <mckenzie.cam@gmail.com>
>> 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 <
>> mckenzie.cam@gmail.com> 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 <
>>> mckenzie.cam@gmail.com> 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 <
>>>> jordan@jordanzimmerman.com> 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 <mckenzie.cam@gmail.com>
>>>>> 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
>>>>> >
>>>>> >
>>>>>
>>>>>
>>>>
>>>
>>
>>
>
>

Mime
View raw message