curator-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mathias Söderberg <math...@burtcorp.com>
Subject Re: Watching Mutex/Semaphore/LeaderSelector for acquisitions
Date Tue, 03 Jun 2014 09:39:40 GMT
I quite like this idea, as we're currently doing something similar (given
that I understand your suggestion correctly), albeit with the LeaderLatch.

In our case, each node sets a watch on each latch znode and populate/change
a local “cache” (more like a registry) when the children of a latch znode
change (but only if it’s possible to actually get a leader from
LeaderLatch#getLeader()).

I suppose it would also be possible have a non-static method that fulfils
the same purpose as well, no?


On Tue, Jun 3, 2014 at 4:07 AM, Jordan Zimmerman <jordan@jordanzimmerman.com
> wrote:

> Would it be wise to add something like “public static void
> watch(CuratorFramework,String path,AcquisitionListener cw,…)” to each of
> these classes to achieve this behavior inside the library in a way that is
> consistent with the implementation of each recipe?  I know it is an
> additional contract to support, but I think it would add value.
>
> I think adding methods to the various classes would be the best approach.
> You might be able to have a general contract via an interface that each of
> the recipes implements with a common listener interface.
>
>
> -JZ
>



-- 

Mathias Söderberg
Software Developer, Burt

www.burtcorp.com
Cell: + 46 762 79 57 55 | Skype: mthssdrbrg
http://twitter.com/mthssdrbrg | http://twitter.com/burtcorp
–––––––––––––––––––––––––––––––––––––––––––

The Analytics Platform for Online Media

Mime
View raw message