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 <[email protected]> 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 <[email protected]> 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 <[email protected]>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 <[email protected]> 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 <[email protected]>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 <[email protected]> >>>>> AT&T, Senior Software Architect >>>>> >>>>> >>>> >>> >> >
