I'm using the Leader Selector on my server nodes (that make up the cluster). Each node instantiates a new LeaderSelector instance, passing itself as a LeaderSelectorListener.
I've just checked and it seems LeaderLatch doesn't require me to register a LeaderSelectorListener, which is good, because I have no purpose to do so on the client... So on my client, I can instantiate a LeaderLatch, start it, query for the leader and then close it. Is this an acceptable pattern? On Sun, Oct 26, 2014 at 10:09 PM, Cameron McKenzie <[email protected]> wrote: > hey Ricardo, > You're using the LeaderLatch recipe? > > There should be a getLeader() method exposed by the LeaderLatch which you > can use to determine the current leader. > cheers > Cam > > On Mon, Oct 27, 2014 at 9:04 AM, Ricardo Ferreira <[email protected]> > wrote: > >> Hi, >> >> I'm using the Leader Election recipe to manage leadership among some of >> my nodes. >> >> However, I need to find out the current leader of these nodes from >> another client which is not >> part of the same group. >> >> I haven't found anything on the API to do this. So what's done is to >> instantiate a new LeaderSelector >> and a dummy LeaderSelectorListener that relinquishes leadership as soon >> as it gets it (just in case). >> From this LeaderSelector I can find the ID of the group leader. Then I'll >> query ServiceDiscovery for >> the instance corresponding to this ID. >> >> Is there a simpler (or better) way to this? >> > >
