Ah, thanks, that makes more sense to me. Having to be elegible for election without wanting it wasn't making much sense.
I'll give it a go tomorrow. Thanks again! On Sun, Oct 26, 2014 at 10:22 PM, Jordan Zimmerman < [email protected]> wrote: > 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? >>> >> >> >
