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 > >
