curator-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jordan Zimmerman <jor...@jordanzimmerman.com>
Subject Re: Curator namespaces
Date Mon, 21 Oct 2013 21:23:01 GMT
If you can think of better doc, I'd appreciate it.

On Oct 21, 2013, at 1:48 PM, Cameron McKenzie <mckenzie.cam@gmail.com> 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 <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