You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@curator.apache.org by Ricardo Ferreira <ri...@gmail.com> on 2015/04/14 15:46:12 UTC
Re: LeaderSelector and ServiceDiscovery together
Anyone?
On Fri, Mar 27, 2015 at 4:30 PM, Ricardo Ferreira <ri...@gmail.com>
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
>
Re: LeaderSelector and ServiceDiscovery together
Posted by Ricardo Ferreira <ri...@gmail.com>.
Alright, thanks for the feedback.
On Wed, Apr 15, 2015 at 10:38 PM, Jordan Zimmerman <
jordan@jordanzimmerman.com> wrote:
> That’s how I would do it. Trying to rely on ordering between Leadership
> and Discovery is too error prone.
>
> -Jordan
>
>
>
> On April 15, 2015 at 11:56:50 AM, Ricardo Ferreira (ricardojsfer@gmail.com)
> wrote:
>
> Anyway, assuming that what I'm doing makes no sense whatsoever, what is
> the standard pattern to have both leadership and service discovery on the
> same members? Are members
> supposed to update their payload when they acquire leadership?
>
>
Re: LeaderSelector and ServiceDiscovery together
Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
That’s how I would do it. Trying to rely on ordering between Leadership and Discovery is too error prone.
-Jordan
On April 15, 2015 at 11:56:50 AM, Ricardo Ferreira (ricardojsfer@gmail.com) wrote:
Anyway, assuming that what I'm doing makes no sense whatsoever, what is the standard pattern to have both leadership and service discovery on the same members? Are members
supposed to update their payload when they acquire leadership?
Re: LeaderSelector and ServiceDiscovery together
Posted by Ricardo Ferreira <ri...@gmail.com>.
Yes, I know they are not related. I'll try to rephrase my question.
When I register a new member on ServiceDiscovery I also add it to
LeaderSelector. As per LeaderSelector semantics, if a leader client exits
the cluster, after a while leader election is triggered
and a new leader will be elected; this member will also be removed from the
ServiceDiscovery.
When I add a new member to the cluster, I add it to both ServiceDiscovery
and LeaderSelector paths. As per LeaderSelector semantics, when ZK detects
that the member left the cluster
leader election is triggered and a new leader is elected; similarly, it
will also be removed from ServiceDiscovery.
What I'm trying to do in this particular method is to return the current
ServiceInstance that is also the current leader (IDs match). To do this I
use LeaderSelector to find out the current leader,
and use ServiceDiscovery to list all members, and then I try to match them.
But sometimes I get a member that is not on ServiceDiscovery (I sometimes
even get an empty list of instances in ServiceDiscovery). I know it's not
the dummy Participant you mentioned
because that returns an empty ID. I tried to use the sync method to avoid
some inconsistency between ZK nodes, as I thought that LeaderSelector's
path could be more up-to-date than ServiceDiscovery's.
But I'm just thinking that LeaderSelector is taking more time to elect a
leader that a member to be removed from ServiceDiscovery, and hence the
inconsistency... Could this be it?
Anyway, assuming that what I'm doing makes no sense whatsoever, what is the
standard pattern to have both leadership and service discovery on the same
members? Are members
supposed to update their payload when they acquire leadership?
On Wed, Apr 15, 2015 at 5:13 PM, Jordan Zimmerman <
jordan@jordanzimmerman.com> wrote:
> 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 (ricardojsfer@gmail.com)
> wrote:
>
> Anyone?
>
> On Fri, Mar 27, 2015 at 4:30 PM, Ricardo Ferreira <ri...@gmail.com>
> 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
>>
>
>
Re: LeaderSelector and ServiceDiscovery together
Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
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 (ricardojsfer@gmail.com) wrote:
Anyone?
On Fri, Mar 27, 2015 at 4:30 PM, Ricardo Ferreira <ri...@gmail.com> 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