Forgot to send this one: Thanks Kanak and Kishore for your response. It helps.
- Henry On Sun, Mar 23, 2014 at 10:58 AM, kishore g <[email protected]> wrote: > All communications in Helix follow Actor pattern. Each participant has a > inbox associated with it. This inbox is modeled as a queue in ZK. Any one > can communicate with a participant by adding a message in this queue. All > participants are always waiting for messages in this queue. Note that > participants can also communicate with each other using the same mechanism. > This should be used as a control channel and not as a data channel. > > The important thing here is note that controller is not pushing messages > directly to participants but instead its pushing them to ZK and > participants are pulling them from ZK. This allows us to scale individual > component independent of each other. Not only that, by using ZK as the > actual communication channel we ensure that all communication is fault > tolerant. > > A message can be of any type and user can register message handlers to > process these messages. > > Most of the communication from controller to participant is in the form of > a transition. On the participant side Helix provides a default > implementation to handle messages of type STATE_TRANSITION. > > State transition message looks like the following > > Resource: MyDB > Partition: MyDB_0 > From_State: Slave > To_State: Master > > User will register the state model transition handler that handles all > transitions. Helix initializes one such handler per (resource,partition) > and invokes the appropriate method based on the transition message. > > Hope this helps > > thanks, > Kishore G > > > > > > > > > > > > > > > > > > > > > > > > > On Sun, Mar 23, 2014 at 9:18 AM, Kanak Biscuitwala <[email protected]>wrote: > >> Hi Henry, >> >> All communication from controller to participant is modeled as a state >> transition. So you create a resource with partitions and replicas to follow >> a state model, and you will automatically get callbacks when it's time to >> transition. >> >> The hope is that you use the built-in helix controller and push app logic >> to participants/spectators. That way, the controller can just tell >> participants what to do in the form of a transition, and the participant >> decides what that means. >> >> Does that make sense? >> >> Kanak >> >> > Date: Sun, 23 Mar 2014 09:12:33 -0700 >> > Subject: Re: Update: New Helix API's >> > From: [email protected] >> > To: [email protected] >> > >> > Quick question, how do you fire event from controller to participants? >> > >> > - Henry >> > >> > On Sat, Mar 22, 2014 at 2:09 PM, kishore g <[email protected]> wrote: >> > > Hi, >> > > >> > > Thanks to Sandeep and Kanak we are getting close to having the new >> > > helix-api package. >> > > >> > > https://github.com/kanakb/helix >> > > >> > > Here is the api package >> > > >> https://github.com/kanakb/helix/tree/master/helix-api/src/main/java/org/apache/helix/api >> > > >> > > Feedback/suggestions? >> > > >> > > >> > > Before we get started working on the roles (administrator, participant, >> > > controller, spectator), we need to wrap up the constraints api. >> > > >> > > At a high level we have state & transition constraints at cluster, >> > > participant, resource, partition granularity. >> > > >> > > We have two options >> > > >> > > #1 Have a separate package called constraints and have >> > > (cluster|participant|resource|partition)Constraint. >> > > >> > > #2. Have StateConstraint & TransitionConstraint as attributes in >> > > (cluster|participant|resource|partition)configuration. >> > > >> > > Thoughts. >> > > >> > > >> > > thanks, >> > > Kishore G >> >>
