You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@helix.apache.org by Erwin Karbasi <er...@optinity.com> on 2013/05/12 18:00:02 UTC
Fwd: Leader election - Distributed lock manager
Hello Masters,
We'd like to use Helix for Leader Election mechanism.
Following our scenario:
We have one server (server A) that need to connect to group of other
servers (server B).
How server A can access the server B's group - cluster.
As I know from other cluster frameworks, we can concatenate multiple server
ip:port and the cluster will pass the requests to the leader process that
in the cluster.
How above scenario could be implemented by using Helix leader election
(Distributed lock manage) as demonstrated here:
http://helix.incubator.apache.org/recipes/lock_manager.html
Your insight would be highly appreciated.
Thanks,
Erwin Karbasi <ek...@att.com>
AT&T, Senior Software Architect
Re: Leader election - Distributed lock manager
Posted by Erwin Karbasi <er...@optinity.com>.
Hi Kapil,
Thank you for fast turnaround response.
You understand partially our requirement.
We don't want to know which server in the group B is the leader, we want
that the server A will send request to the group of servers of a group and
only one server from group B (that is the leader) will pick up the requests
and other server would be standby.
If the leader goes down other group's member will take the place of leader
and will get the requests.
Server A don't know which server from group B is the leader, thus server A
send requests to the group (concatenation of all group members
ip1:port1,ip2:port2,...,ipn:portn).
Erwin Karbasi
AT&T, Senior Software Architect
On Sun, May 12, 2013 at 7:31 PM, Kapil Surlaker <ka...@gmail.com>wrote:
> Erwin:
>
> If I understand your usecase correctly, you want to pick one server in
> group B as a Leader and have server A connect to that Leader. You can
> accomplish that by using a LeaderStandBy state model (available in Helix)
> for the cluster. Server group B will be participants of that cluster, while
> server A will be a spectator and can pass the requests to the Leader by
> having the External View of the cluster.
>
> Does that satisfy your usecase?
>
> Thanks,
> Kapil
>
>
>
> On Sun, May 12, 2013 at 9:00 AM, Erwin Karbasi <er...@optinity.com> wrote:
>
>>
>> Hello Masters,
>>
>> We'd like to use Helix for Leader Election mechanism.
>> Following our scenario:
>>
>> We have one server (server A) that need to connect to group of other
>> servers (server B).
>> How server A can access the server B's group - cluster.
>>
>> As I know from other cluster frameworks, we can concatenate multiple
>> server ip:port and the cluster will pass the requests to the leader process
>> that in the cluster.
>>
>> How above scenario could be implemented by using Helix leader election
>> (Distributed lock manage) as demonstrated here:
>> http://helix.incubator.apache.org/recipes/lock_manager.html
>>
>> Your insight would be highly appreciated.
>>
>> Thanks,
>> Erwin Karbasi <ek...@att.com>
>> AT&T, Senior Software Architect
>>
>>
>
Re: Leader election - Distributed lock manager
Posted by Kapil Surlaker <ka...@gmail.com>.
Erwin:
If I understand your usecase correctly, you want to pick one server in
group B as a Leader and have server A connect to that Leader. You can
accomplish that by using a LeaderStandBy state model (available in Helix)
for the cluster. Server group B will be participants of that cluster, while
server A will be a spectator and can pass the requests to the Leader by
having the External View of the cluster.
Does that satisfy your usecase?
Thanks,
Kapil
On Sun, May 12, 2013 at 9:00 AM, Erwin Karbasi <er...@optinity.com> wrote:
>
> Hello Masters,
>
> We'd like to use Helix for Leader Election mechanism.
> Following our scenario:
>
> We have one server (server A) that need to connect to group of other
> servers (server B).
> How server A can access the server B's group - cluster.
>
> As I know from other cluster frameworks, we can concatenate multiple
> server ip:port and the cluster will pass the requests to the leader process
> that in the cluster.
>
> How above scenario could be implemented by using Helix leader election
> (Distributed lock manage) as demonstrated here:
> http://helix.incubator.apache.org/recipes/lock_manager.html
>
> Your insight would be highly appreciated.
>
> Thanks,
> Erwin Karbasi <ek...@att.com>
> AT&T, Senior Software Architect
>
>
Re: Leader election - Distributed lock manager
Posted by Erwin Karbasi <er...@optinity.com>.
Thank you a lot Kishore.
Your first pointed out option could be appropriate to our requirement.
If the Server A will get up to date routing table from the server group B,
it could be sufficient.
Our requirement is that server A will access one of the members in cluster
B (that is the leader) and this leader will be active for any operation.
After that server will be unavailable other member in the cluster B will
take the place of the leader, but server B should be updated about this
change.
Thanks again,
Erwin
On Sun, May 12, 2013 at 8:44 PM, kishore g <g....@gmail.com> wrote:
> Hi Erwin,
>
> The code i sent basically shows how Server A can send the request directly
> to current Leader in server B group. Note, when leader changes in server B,
> server A dynamically discovers that change and updates it routing table.
>
> But looks like what you want is server A sends request to any one of the
> server in Server B cluster and that server will re-direct the request to
> the leader. In this case, the code i sent you must be included in every
> server in Server B group. To server A you can simply provide list of
> ip:port address and it can randomly select one of server and send the
> request to it.
>
>
> thanks,
> Kishore G
>
>
>
>
> On Sun, May 12, 2013 at 10:27 AM, Erwin Karbasi <er...@optinity.com>wrote:
>
>> Hi Kishroe,
>>
>> Thank for the information.
>> I'll deep dive into the code that you sent tomorrow.
>> Is that code will ensure that I have one cluster that i can send to it
>> requests and one member from that cluster (leader) will grab the request
>> and treat it.
>>
>> Thanks again,
>> Erwin Karbasi
>> AT&T, Senior Software Architect
>>
>>
>> On Sun, May 12, 2013 at 7:57 PM, kishore g <g....@gmail.com> wrote:
>>
>>> Hi Erwin,
>>>
>>> Thanks for looking into Helix. In Helix, most of the time the only
>>> configuration needed is the zookeeper address and cluster name. This is the
>>> code you can use to contact a server.
>>>
>>> //in the server A code at start up
>>> final RoutingTableProvider routingTable = new RoutingTableProvider();
>>> //Default Externalview implementation
>>> manager = HelixManagerFactory.getZKHelixManager(clusterName,
>>> instanceName, InstanceType.SPECTATOR, zkConnectString)
>>> manager.connect();
>>> manager.addExternalViewChangeListener(routingTable)
>>>
>>>
>>>
>>>
>>>
>>>
>>> //Any time you want to talk to servers B
>>> //you can get a instances for a specific resource, partition in specific state. e.g getInstances("LockGroup", "lockGroup_0", "LEADER");
>>>
>>>
>>>
>>>
>>> List<InstanceConfig> instances = getInstances(String resourceName, String partitionName, String state)
>>>
>>>
>>>
>>>
>>>
>>> //Get all instances in given resource in a specific state e.g getInstances("LockGroup", "LEADER");
>>> Set<InstanceConfig> instances = getInstances(String resource, String state)
>>>
>>>
>>>
>>>
>>>
>>>
>>> InstanceConfig can give you all details about the server like host, port
>>> or anything else you want to add.
>>>
>>> Hope this helps. Thanks for bringing this up, we need to add an example
>>> code for this.
>>>
>>> Thanks,
>>> Kishore G
>>>
>>> On Sun, May 12, 2013 at 9:00 AM, Erwin Karbasi <er...@optinity.com>wrote:
>>>
>>>>
>>>> Hello Masters,
>>>>
>>>> We'd like to use Helix for Leader Election mechanism.
>>>> Following our scenario:
>>>>
>>>> We have one server (server A) that need to connect to group of other
>>>> servers (server B).
>>>> How server A can access the server B's group - cluster.
>>>>
>>>> As I know from other cluster frameworks, we can concatenate multiple
>>>> server ip:port and the cluster will pass the requests to the leader process
>>>> that in the cluster.
>>>>
>>>> How above scenario could be implemented by using Helix leader election
>>>> (Distributed lock manage) as demonstrated here:
>>>> http://helix.incubator.apache.org/recipes/lock_manager.html
>>>>
>>>> Your insight would be highly appreciated.
>>>>
>>>> Thanks,
>>>> Erwin Karbasi <ek...@att.com>
>>>> AT&T, Senior Software Architect
>>>>
>>>>
>>>
>>
>
Re: Leader election - Distributed lock manager
Posted by Erwin Karbasi <er...@optinity.com>.
Hi Kishore,
Thanks for clarification.
Leader-Standby with Spectator example code would be significantly helpful.
Thanks,
Erwin
On Mon, May 13, 2013 at 6:50 PM, kishore g <g....@gmail.com> wrote:
> Hi Erwin,
>
> Both Master-Slave and Leader-Standby have offline states. There are two
> differences
>
> 1)Just a standard convention where master-slave means there is some kind
> of replication of data between master and slave which means slave is not
> idle. In case of LeaderStandBy, there is no data movement between the
> leader standby nodes and in most cases standby is idle until it is asked
> to become leader.
>
> 2) Other difference is the state machine, to become a master one should
> always become a slave, but in case of leader standby, there is no need to
> be in standby mode to become a leader.
>
> Thanks,
> Kishore G
>
>
>
>
>
> On Mon, May 13, 2013 at 8:21 AM, Erwin Karbasi <er...@optinity.com> wrote:
>
>> Hello All,
>>
>> IMO, the most appropriate demo for our use case is the Rsync replicated
>> file system
>> http://helix.incubator.apache.org/recipes/rsync_replicated_file_store.html
>> .
>>
>> Is it correct that the ONLY difference between Leader-Standby and
>> Master-Slave state models is that Master-Slave has one more state that
>> calls Offline?
>>
>> Thanks,
>> Erwin
>>
>>
>>
>> On Mon, May 13, 2013 at 7:46 AM, Erwin Karbasi <er...@optinity.com>wrote:
>>
>>> *Sorry, same message with typo correction.*
>>>
>>>
>>> hank you a lot Kishore.
>>> Your first pointed out option could be appropriate to our requirement.
>>> If the Server A will get up to date routing table from the server group
>>> B, it could be sufficient.
>>>
>>> Our requirement is that server A will access one of the members in
>>> cluster B (that is the leader) and this leader will be active for any
>>> operation. After that server will be unavailable other member in the
>>> cluster B will take the place of the leader, *but server A should be
>>> updated about this change.
>>> *
>>> Thanks again,
>>> Erwin
>>>
>>> On Sun, May 12, 2013 at 8:44 PM, kishore g <g....@gmail.com> wrote:
>>>
>>>> Hi Erwin,
>>>>
>>>> The code i sent basically shows how Server A can send the request
>>>> directly to current Leader in server B group. Note, when leader changes in
>>>> server B, server A dynamically discovers that change and updates it routing
>>>> table.
>>>>
>>>> But looks like what you want is server A sends request to any one of
>>>> the server in Server B cluster and that server will re-direct the request
>>>> to the leader. In this case, the code i sent you must be included in every
>>>> server in Server B group. To server A you can simply provide list of
>>>> ip:port address and it can randomly select one of server and send the
>>>> request to it.
>>>>
>>>>
>>>> thanks,
>>>> Kishore G
>>>>
>>>>
>>>>
>>>>
>>>> On Sun, May 12, 2013 at 10:27 AM, Erwin Karbasi <er...@optinity.com>wrote:
>>>>
>>>>> Hi Kishroe,
>>>>>
>>>>> Thank for the information.
>>>>> I'll deep dive into the code that you sent tomorrow.
>>>>> Is that code will ensure that I have one cluster that i can send to it
>>>>> requests and one member from that cluster (leader) will grab the request
>>>>> and treat it.
>>>>>
>>>>> Thanks again,
>>>>> Erwin Karbasi
>>>>> AT&T, Senior Software Architect
>>>>>
>>>>>
>>>>> On Sun, May 12, 2013 at 7:57 PM, kishore g <g....@gmail.com>wrote:
>>>>>
>>>>>> Hi Erwin,
>>>>>>
>>>>>> Thanks for looking into Helix. In Helix, most of the time the only
>>>>>> configuration needed is the zookeeper address and cluster name. This is the
>>>>>> code you can use to contact a server.
>>>>>>
>>>>>> //in the server A code at start up
>>>>>> final RoutingTableProvider routingTable = new RoutingTableProvider();
>>>>>> //Default Externalview implementation
>>>>>> manager = HelixManagerFactory.getZKHelixManager(clusterName,
>>>>>> instanceName, InstanceType.SPECTATOR, zkConnectString)
>>>>>> manager.connect();
>>>>>> manager.addExternalViewChangeListener(routingTable)
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> //Any time you want to talk to servers B
>>>>>> //you can get a instances for a specific resource, partition in specific state. e.g getInstances("LockGroup", "lockGroup_0", "LEADER");
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> List<InstanceConfig> instances = getInstances(String resourceName, String partitionName, String state)
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> //Get all instances in given resource in a specific state e.g getInstances("LockGroup", "LEADER");
>>>>>> Set<InstanceConfig> instances = getInstances(String resource, String state)
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> InstanceConfig can give you all details about the server like host,
>>>>>> port or anything else you want to add.
>>>>>>
>>>>>> Hope this helps. Thanks for bringing this up, we need to add an
>>>>>> example code for this.
>>>>>>
>>>>>> Thanks,
>>>>>> Kishore G
>>>>>>
>>>>>> On Sun, May 12, 2013 at 9:00 AM, Erwin Karbasi <er...@optinity.com>wrote:
>>>>>>
>>>>>>>
>>>>>>> Hello Masters,
>>>>>>>
>>>>>>> We'd like to use Helix for Leader Election mechanism.
>>>>>>> Following our scenario:
>>>>>>>
>>>>>>> We have one server (server A) that need to connect to group of other
>>>>>>> servers (server B).
>>>>>>> How server A can access the server B's group - cluster.
>>>>>>>
>>>>>>> As I know from other cluster frameworks, we can concatenate multiple
>>>>>>> server ip:port and the cluster will pass the requests to the leader process
>>>>>>> that in the cluster.
>>>>>>>
>>>>>>> How above scenario could be implemented by using Helix leader
>>>>>>> election (Distributed lock manage) as demonstrated here:
>>>>>>> http://helix.incubator.apache.org/recipes/lock_manager.html
>>>>>>>
>>>>>>> Your insight would be highly appreciated.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Erwin Karbasi <ek...@att.com>
>>>>>>> AT&T, Senior Software Architect
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: Leader election - Distributed lock manager
Posted by kishore g <g....@gmail.com>.
Hi Erwin,
Both Master-Slave and Leader-Standby have offline states. There are two
differences
1)Just a standard convention where master-slave means there is some kind of
replication of data between master and slave which means slave is not idle.
In case of LeaderStandBy, there is no data movement between the leader
standby nodes and in most cases standby is idle until it is asked to
become leader.
2) Other difference is the state machine, to become a master one should
always become a slave, but in case of leader standby, there is no need to
be in standby mode to become a leader.
Thanks,
Kishore G
On Mon, May 13, 2013 at 8:21 AM, Erwin Karbasi <er...@optinity.com> wrote:
> Hello All,
>
> IMO, the most appropriate demo for our use case is the Rsync replicated
> file system
> http://helix.incubator.apache.org/recipes/rsync_replicated_file_store.html
> .
>
> Is it correct that the ONLY difference between Leader-Standby and
> Master-Slave state models is that Master-Slave has one more state that
> calls Offline?
>
> Thanks,
> Erwin
>
>
>
> On Mon, May 13, 2013 at 7:46 AM, Erwin Karbasi <er...@optinity.com> wrote:
>
>> *Sorry, same message with typo correction.*
>>
>>
>> hank you a lot Kishore.
>> Your first pointed out option could be appropriate to our requirement.
>> If the Server A will get up to date routing table from the server group
>> B, it could be sufficient.
>>
>> Our requirement is that server A will access one of the members in
>> cluster B (that is the leader) and this leader will be active for any
>> operation. After that server will be unavailable other member in the
>> cluster B will take the place of the leader, *but server A should be
>> updated about this change.
>> *
>> Thanks again,
>> Erwin
>>
>> On Sun, May 12, 2013 at 8:44 PM, kishore g <g....@gmail.com> wrote:
>>
>>> Hi Erwin,
>>>
>>> The code i sent basically shows how Server A can send the request
>>> directly to current Leader in server B group. Note, when leader changes in
>>> server B, server A dynamically discovers that change and updates it routing
>>> table.
>>>
>>> But looks like what you want is server A sends request to any one of the
>>> server in Server B cluster and that server will re-direct the request to
>>> the leader. In this case, the code i sent you must be included in every
>>> server in Server B group. To server A you can simply provide list of
>>> ip:port address and it can randomly select one of server and send the
>>> request to it.
>>>
>>>
>>> thanks,
>>> Kishore G
>>>
>>>
>>>
>>>
>>> On Sun, May 12, 2013 at 10:27 AM, Erwin Karbasi <er...@optinity.com>wrote:
>>>
>>>> Hi Kishroe,
>>>>
>>>> Thank for the information.
>>>> I'll deep dive into the code that you sent tomorrow.
>>>> Is that code will ensure that I have one cluster that i can send to it
>>>> requests and one member from that cluster (leader) will grab the request
>>>> and treat it.
>>>>
>>>> Thanks again,
>>>> Erwin Karbasi
>>>> AT&T, Senior Software Architect
>>>>
>>>>
>>>> On Sun, May 12, 2013 at 7:57 PM, kishore g <g....@gmail.com> wrote:
>>>>
>>>>> Hi Erwin,
>>>>>
>>>>> Thanks for looking into Helix. In Helix, most of the time the only
>>>>> configuration needed is the zookeeper address and cluster name. This is the
>>>>> code you can use to contact a server.
>>>>>
>>>>> //in the server A code at start up
>>>>> final RoutingTableProvider routingTable = new RoutingTableProvider();
>>>>> //Default Externalview implementation
>>>>> manager = HelixManagerFactory.getZKHelixManager(clusterName,
>>>>> instanceName, InstanceType.SPECTATOR, zkConnectString)
>>>>> manager.connect();
>>>>> manager.addExternalViewChangeListener(routingTable)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> //Any time you want to talk to servers B
>>>>> //you can get a instances for a specific resource, partition in specific state. e.g getInstances("LockGroup", "lockGroup_0", "LEADER");
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> List<InstanceConfig> instances = getInstances(String resourceName, String partitionName, String state)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> //Get all instances in given resource in a specific state e.g getInstances("LockGroup", "LEADER");
>>>>> Set<InstanceConfig> instances = getInstances(String resource, String state)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> InstanceConfig can give you all details about the server like host,
>>>>> port or anything else you want to add.
>>>>>
>>>>> Hope this helps. Thanks for bringing this up, we need to add an
>>>>> example code for this.
>>>>>
>>>>> Thanks,
>>>>> Kishore G
>>>>>
>>>>> On Sun, May 12, 2013 at 9:00 AM, Erwin Karbasi <er...@optinity.com>wrote:
>>>>>
>>>>>>
>>>>>> Hello Masters,
>>>>>>
>>>>>> We'd like to use Helix for Leader Election mechanism.
>>>>>> Following our scenario:
>>>>>>
>>>>>> We have one server (server A) that need to connect to group of other
>>>>>> servers (server B).
>>>>>> How server A can access the server B's group - cluster.
>>>>>>
>>>>>> As I know from other cluster frameworks, we can concatenate multiple
>>>>>> server ip:port and the cluster will pass the requests to the leader process
>>>>>> that in the cluster.
>>>>>>
>>>>>> How above scenario could be implemented by using Helix leader
>>>>>> election (Distributed lock manage) as demonstrated here:
>>>>>> http://helix.incubator.apache.org/recipes/lock_manager.html
>>>>>>
>>>>>> Your insight would be highly appreciated.
>>>>>>
>>>>>> Thanks,
>>>>>> Erwin Karbasi <ek...@att.com>
>>>>>> AT&T, Senior Software Architect
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: Leader election - Distributed lock manager
Posted by Erwin Karbasi <er...@optinity.com>.
Hello All,
IMO, the most appropriate demo for our use case is the Rsync replicated
file system
http://helix.incubator.apache.org/recipes/rsync_replicated_file_store.html.
Is it correct that the ONLY difference between Leader-Standby and
Master-Slave state models is that Master-Slave has one more state that
calls Offline?
Thanks,
Erwin
On Mon, May 13, 2013 at 7:46 AM, Erwin Karbasi <er...@optinity.com> wrote:
> *Sorry, same message with typo correction.*
>
>
> hank you a lot Kishore.
> Your first pointed out option could be appropriate to our requirement.
> If the Server A will get up to date routing table from the server group B,
> it could be sufficient.
>
> Our requirement is that server A will access one of the members in cluster
> B (that is the leader) and this leader will be active for any operation.
> After that server will be unavailable other member in the cluster B will
> take the place of the leader, *but server A should be updated about this
> change.
> *
> Thanks again,
> Erwin
>
> On Sun, May 12, 2013 at 8:44 PM, kishore g <g....@gmail.com> wrote:
>
>> Hi Erwin,
>>
>> The code i sent basically shows how Server A can send the request
>> directly to current Leader in server B group. Note, when leader changes in
>> server B, server A dynamically discovers that change and updates it routing
>> table.
>>
>> But looks like what you want is server A sends request to any one of the
>> server in Server B cluster and that server will re-direct the request to
>> the leader. In this case, the code i sent you must be included in every
>> server in Server B group. To server A you can simply provide list of
>> ip:port address and it can randomly select one of server and send the
>> request to it.
>>
>>
>> thanks,
>> Kishore G
>>
>>
>>
>>
>> On Sun, May 12, 2013 at 10:27 AM, Erwin Karbasi <er...@optinity.com>wrote:
>>
>>> Hi Kishroe,
>>>
>>> Thank for the information.
>>> I'll deep dive into the code that you sent tomorrow.
>>> Is that code will ensure that I have one cluster that i can send to it
>>> requests and one member from that cluster (leader) will grab the request
>>> and treat it.
>>>
>>> Thanks again,
>>> Erwin Karbasi
>>> AT&T, Senior Software Architect
>>>
>>>
>>> On Sun, May 12, 2013 at 7:57 PM, kishore g <g....@gmail.com> wrote:
>>>
>>>> Hi Erwin,
>>>>
>>>> Thanks for looking into Helix. In Helix, most of the time the only
>>>> configuration needed is the zookeeper address and cluster name. This is the
>>>> code you can use to contact a server.
>>>>
>>>> //in the server A code at start up
>>>> final RoutingTableProvider routingTable = new RoutingTableProvider();
>>>> //Default Externalview implementation
>>>> manager = HelixManagerFactory.getZKHelixManager(clusterName,
>>>> instanceName, InstanceType.SPECTATOR, zkConnectString)
>>>> manager.connect();
>>>> manager.addExternalViewChangeListener(routingTable)
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> //Any time you want to talk to servers B
>>>> //you can get a instances for a specific resource, partition in specific state. e.g getInstances("LockGroup", "lockGroup_0", "LEADER");
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> List<InstanceConfig> instances = getInstances(String resourceName, String partitionName, String state)
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> //Get all instances in given resource in a specific state e.g getInstances("LockGroup", "LEADER");
>>>> Set<InstanceConfig> instances = getInstances(String resource, String state)
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> InstanceConfig can give you all details about the server like host,
>>>> port or anything else you want to add.
>>>>
>>>> Hope this helps. Thanks for bringing this up, we need to add an example
>>>> code for this.
>>>>
>>>> Thanks,
>>>> Kishore G
>>>>
>>>> On Sun, May 12, 2013 at 9:00 AM, Erwin Karbasi <er...@optinity.com>wrote:
>>>>
>>>>>
>>>>> Hello Masters,
>>>>>
>>>>> We'd like to use Helix for Leader Election mechanism.
>>>>> Following our scenario:
>>>>>
>>>>> We have one server (server A) that need to connect to group of other
>>>>> servers (server B).
>>>>> How server A can access the server B's group - cluster.
>>>>>
>>>>> As I know from other cluster frameworks, we can concatenate multiple
>>>>> server ip:port and the cluster will pass the requests to the leader process
>>>>> that in the cluster.
>>>>>
>>>>> How above scenario could be implemented by using Helix leader election
>>>>> (Distributed lock manage) as demonstrated here:
>>>>> http://helix.incubator.apache.org/recipes/lock_manager.html
>>>>>
>>>>> Your insight would be highly appreciated.
>>>>>
>>>>> Thanks,
>>>>> Erwin Karbasi <ek...@att.com>
>>>>> AT&T, Senior Software Architect
>>>>>
>>>>>
>>>>
>>>
>>
>
Re: Leader election - Distributed lock manager
Posted by Erwin Karbasi <er...@optinity.com>.
*Sorry, same message with typo correction.*
hank you a lot Kishore.
Your first pointed out option could be appropriate to our requirement.
If the Server A will get up to date routing table from the server group B,
it could be sufficient.
Our requirement is that server A will access one of the members in cluster
B (that is the leader) and this leader will be active for any operation.
After that server will be unavailable other member in the cluster B will
take the place of the leader, *but server A should be updated about this
change.
*
Thanks again,
Erwin
On Sun, May 12, 2013 at 8:44 PM, kishore g <g....@gmail.com> wrote:
> Hi Erwin,
>
> The code i sent basically shows how Server A can send the request directly
> to current Leader in server B group. Note, when leader changes in server B,
> server A dynamically discovers that change and updates it routing table.
>
> But looks like what you want is server A sends request to any one of the
> server in Server B cluster and that server will re-direct the request to
> the leader. In this case, the code i sent you must be included in every
> server in Server B group. To server A you can simply provide list of
> ip:port address and it can randomly select one of server and send the
> request to it.
>
>
> thanks,
> Kishore G
>
>
>
>
> On Sun, May 12, 2013 at 10:27 AM, Erwin Karbasi <er...@optinity.com>wrote:
>
>> Hi Kishroe,
>>
>> Thank for the information.
>> I'll deep dive into the code that you sent tomorrow.
>> Is that code will ensure that I have one cluster that i can send to it
>> requests and one member from that cluster (leader) will grab the request
>> and treat it.
>>
>> Thanks again,
>> Erwin Karbasi
>> AT&T, Senior Software Architect
>>
>>
>> On Sun, May 12, 2013 at 7:57 PM, kishore g <g....@gmail.com> wrote:
>>
>>> Hi Erwin,
>>>
>>> Thanks for looking into Helix. In Helix, most of the time the only
>>> configuration needed is the zookeeper address and cluster name. This is the
>>> code you can use to contact a server.
>>>
>>> //in the server A code at start up
>>> final RoutingTableProvider routingTable = new RoutingTableProvider();
>>> //Default Externalview implementation
>>> manager = HelixManagerFactory.getZKHelixManager(clusterName,
>>> instanceName, InstanceType.SPECTATOR, zkConnectString)
>>> manager.connect();
>>> manager.addExternalViewChangeListener(routingTable)
>>>
>>>
>>>
>>>
>>>
>>>
>>> //Any time you want to talk to servers B
>>> //you can get a instances for a specific resource, partition in specific state. e.g getInstances("LockGroup", "lockGroup_0", "LEADER");
>>>
>>>
>>>
>>>
>>> List<InstanceConfig> instances = getInstances(String resourceName, String partitionName, String state)
>>>
>>>
>>>
>>>
>>>
>>> //Get all instances in given resource in a specific state e.g getInstances("LockGroup", "LEADER");
>>> Set<InstanceConfig> instances = getInstances(String resource, String state)
>>>
>>>
>>>
>>>
>>>
>>>
>>> InstanceConfig can give you all details about the server like host, port
>>> or anything else you want to add.
>>>
>>> Hope this helps. Thanks for bringing this up, we need to add an example
>>> code for this.
>>>
>>> Thanks,
>>> Kishore G
>>>
>>> On Sun, May 12, 2013 at 9:00 AM, Erwin Karbasi <er...@optinity.com>wrote:
>>>
>>>>
>>>> Hello Masters,
>>>>
>>>> We'd like to use Helix for Leader Election mechanism.
>>>> Following our scenario:
>>>>
>>>> We have one server (server A) that need to connect to group of other
>>>> servers (server B).
>>>> How server A can access the server B's group - cluster.
>>>>
>>>> As I know from other cluster frameworks, we can concatenate multiple
>>>> server ip:port and the cluster will pass the requests to the leader process
>>>> that in the cluster.
>>>>
>>>> How above scenario could be implemented by using Helix leader election
>>>> (Distributed lock manage) as demonstrated here:
>>>> http://helix.incubator.apache.org/recipes/lock_manager.html
>>>>
>>>> Your insight would be highly appreciated.
>>>>
>>>> Thanks,
>>>> Erwin Karbasi <ek...@att.com>
>>>> AT&T, Senior Software Architect
>>>>
>>>>
>>>
>>
>
Re: Leader election - Distributed lock manager
Posted by kishore g <g....@gmail.com>.
Hi Erwin,
The code i sent basically shows how Server A can send the request directly
to current Leader in server B group. Note, when leader changes in server B,
server A dynamically discovers that change and updates it routing table.
But looks like what you want is server A sends request to any one of the
server in Server B cluster and that server will re-direct the request to
the leader. In this case, the code i sent you must be included in every
server in Server B group. To server A you can simply provide list of
ip:port address and it can randomly select one of server and send the
request to it.
thanks,
Kishore G
On Sun, May 12, 2013 at 10:27 AM, Erwin Karbasi <er...@optinity.com> wrote:
> Hi Kishroe,
>
> Thank for the information.
> I'll deep dive into the code that you sent tomorrow.
> Is that code will ensure that I have one cluster that i can send to it
> requests and one member from that cluster (leader) will grab the request
> and treat it.
>
> Thanks again,
> Erwin Karbasi
> AT&T, Senior Software Architect
>
>
> On Sun, May 12, 2013 at 7:57 PM, kishore g <g....@gmail.com> wrote:
>
>> Hi Erwin,
>>
>> Thanks for looking into Helix. In Helix, most of the time the only
>> configuration needed is the zookeeper address and cluster name. This is the
>> code you can use to contact a server.
>>
>> //in the server A code at start up
>> final RoutingTableProvider routingTable = new RoutingTableProvider();
>> //Default Externalview implementation
>> manager = HelixManagerFactory.getZKHelixManager(clusterName, instanceName
>> , InstanceType.SPECTATOR, zkConnectString)
>> manager.connect();
>> manager.addExternalViewChangeListener(routingTable)
>>
>>
>>
>>
>> //Any time you want to talk to servers B
>> //you can get a instances for a specific resource, partition in specific state. e.g getInstances("LockGroup", "lockGroup_0", "LEADER");
>>
>>
>> List<InstanceConfig> instances = getInstances(String resourceName, String partitionName, String state)
>>
>>
>>
>> //Get all instances in given resource in a specific state e.g getInstances("LockGroup", "LEADER");
>> Set<InstanceConfig> instances = getInstances(String resource, String state)
>>
>>
>>
>>
>> InstanceConfig can give you all details about the server like host, port
>> or anything else you want to add.
>>
>> Hope this helps. Thanks for bringing this up, we need to add an example
>> code for this.
>>
>> Thanks,
>> Kishore G
>>
>> On Sun, May 12, 2013 at 9:00 AM, Erwin Karbasi <er...@optinity.com>wrote:
>>
>>>
>>> Hello Masters,
>>>
>>> We'd like to use Helix for Leader Election mechanism.
>>> Following our scenario:
>>>
>>> We have one server (server A) that need to connect to group of other
>>> servers (server B).
>>> How server A can access the server B's group - cluster.
>>>
>>> As I know from other cluster frameworks, we can concatenate multiple
>>> server ip:port and the cluster will pass the requests to the leader process
>>> that in the cluster.
>>>
>>> How above scenario could be implemented by using Helix leader election
>>> (Distributed lock manage) as demonstrated here:
>>> http://helix.incubator.apache.org/recipes/lock_manager.html
>>>
>>> Your insight would be highly appreciated.
>>>
>>> Thanks,
>>> Erwin Karbasi <ek...@att.com>
>>> AT&T, Senior Software Architect
>>>
>>>
>>
>
Re: Leader election - Distributed lock manager
Posted by Erwin Karbasi <er...@optinity.com>.
Hi Kishroe,
Thank for the information.
I'll deep dive into the code that you sent tomorrow.
Is that code will ensure that I have one cluster that i can send to it
requests and one member from that cluster (leader) will grab the request
and treat it.
Thanks again,
Erwin Karbasi
AT&T, Senior Software Architect
On Sun, May 12, 2013 at 7:57 PM, kishore g <g....@gmail.com> wrote:
> Hi Erwin,
>
> Thanks for looking into Helix. In Helix, most of the time the only
> configuration needed is the zookeeper address and cluster name. This is the
> code you can use to contact a server.
>
> //in the server A code at start up
> final RoutingTableProvider routingTable = new RoutingTableProvider();
> //Default Externalview implementation
> manager = HelixManagerFactory.getZKHelixManager(clusterName, instanceName,
> InstanceType.SPECTATOR, zkConnectString)
> manager.connect();
> manager.addExternalViewChangeListener(routingTable)
>
>
>
> //Any time you want to talk to servers B
> //you can get a instances for a specific resource, partition in specific state. e.g getInstances("LockGroup", "lockGroup_0", "LEADER");
>
> List<InstanceConfig> instances = getInstances(String resourceName, String partitionName, String state)
>
>
> //Get all instances in given resource in a specific state e.g getInstances("LockGroup", "LEADER");
> Set<InstanceConfig> instances = getInstances(String resource, String state)
>
>
>
> InstanceConfig can give you all details about the server like host, port
> or anything else you want to add.
>
> Hope this helps. Thanks for bringing this up, we need to add an example
> code for this.
>
> Thanks,
> Kishore G
>
> On Sun, May 12, 2013 at 9:00 AM, Erwin Karbasi <er...@optinity.com> wrote:
>
>>
>> Hello Masters,
>>
>> We'd like to use Helix for Leader Election mechanism.
>> Following our scenario:
>>
>> We have one server (server A) that need to connect to group of other
>> servers (server B).
>> How server A can access the server B's group - cluster.
>>
>> As I know from other cluster frameworks, we can concatenate multiple
>> server ip:port and the cluster will pass the requests to the leader process
>> that in the cluster.
>>
>> How above scenario could be implemented by using Helix leader election
>> (Distributed lock manage) as demonstrated here:
>> http://helix.incubator.apache.org/recipes/lock_manager.html
>>
>> Your insight would be highly appreciated.
>>
>> Thanks,
>> Erwin Karbasi <ek...@att.com>
>> AT&T, Senior Software Architect
>>
>>
>
Re: Leader election - Distributed lock manager
Posted by kishore g <g....@gmail.com>.
Hi Erwin,
Thanks for looking into Helix. In Helix, most of the time the only
configuration needed is the zookeeper address and cluster name. This is the
code you can use to contact a server.
//in the server A code at start up
final RoutingTableProvider routingTable = new RoutingTableProvider();
//Default Externalview implementation
manager = HelixManagerFactory.getZKHelixManager(clusterName, instanceName,
InstanceType.SPECTATOR, zkConnectString)
manager.connect();
manager.addExternalViewChangeListener(routingTable)
//Any time you want to talk to servers B
//you can get a instances for a specific resource, partition in
specific state. e.g getInstances("LockGroup", "lockGroup_0",
"LEADER");
List<InstanceConfig> instances = getInstances(String resourceName,
String partitionName, String state)
//Get all instances in given resource in a specific state e.g
getInstances("LockGroup", "LEADER");
Set<InstanceConfig> instances = getInstances(String resource, String state)
InstanceConfig can give you all details about the server like host, port or
anything else you want to add.
Hope this helps. Thanks for bringing this up, we need to add an example
code for this.
Thanks,
Kishore G
On Sun, May 12, 2013 at 9:00 AM, Erwin Karbasi <er...@optinity.com> wrote:
>
> Hello Masters,
>
> We'd like to use Helix for Leader Election mechanism.
> Following our scenario:
>
> We have one server (server A) that need to connect to group of other
> servers (server B).
> How server A can access the server B's group - cluster.
>
> As I know from other cluster frameworks, we can concatenate multiple
> server ip:port and the cluster will pass the requests to the leader process
> that in the cluster.
>
> How above scenario could be implemented by using Helix leader election
> (Distributed lock manage) as demonstrated here:
> http://helix.incubator.apache.org/recipes/lock_manager.html
>
> Your insight would be highly appreciated.
>
> Thanks,
> Erwin Karbasi <ek...@att.com>
> AT&T, Senior Software Architect
>
>