For both LeaderSelector and LeaderLatch, you don’t have to start them to call getParticipants(). Just allocate one, call getParticipants() and then you’re done.
On October 26, 2014 at 5:20:46 PM, Ricardo Ferreira ([email protected]) wrote: 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?
