I don’t understand what’s shown in your example. LeaderSelector and ServiceDiscovery are not related. One thing I can say is that there isn’t always going to be a leader. If an election is in process getLeader() might return a dummy participant.
-Jordan On April 14, 2015 at 8:46:59 AM, Ricardo Ferreira ([email protected]) wrote: Anyone? On Fri, Mar 27, 2015 at 4:30 PM, Ricardo Ferreira <[email protected]> wrote: Hello all, I'm building a system that uses both LeaderSelector and ServiceDiscovery recipes. When I want to retrieve the leader Service, I use the following code: ``` LeaderSelector leaderSelector = new LeaderSelector(curatorFramework, serviceLeaderPath, new LeaderSelectorListenerAdapter() { @Override public void takeLeadership(final CuratorFramework curatorFramework) throws Exception { // Return immediately. This is a dummy listener that will never be called // because we won't start this LeaderSelector instance. } }); Participant leader = leaderSelector.getLeader(); ``` This allows me to retrieve the ID the leader. But as I want the Service's instance, I then retrieve it from ServiceDiscovery: ``` ServiceInstance<T> leaderServiceInstance = serviceDiscovery.queryForInstance(serviceName, leader.getId()); ``` This works as expected most of the times. However, sometimes I experience some inconsistencies between the two, where a leader that doesn't exist in ServiceDiscovery is retrieved. I've seen this with no disturbance in the ensemble (i.e. all nodes up, local network). I've attempted to mitigate this by forcing a synchronize call to the leader election path before calling leader selector, but to no avail. I might be misinterpreting it though: ``` getCuratorFrameworkInstance().sync().forPath(serviceLeaderPath); Participant leader = leaderSelector.getLeader(); ``` Is there a way to force these paths to be up-to-date? Best regards, Ricardo Ferreiar
