[ https://issues.apache.org/jira/browse/HELIX-56?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15674315#comment-15674315 ]
Lei Xia commented on HELIX-56: ------------------------------ We have a new design on this, will send out my proposed design and changes for review soon. > Delayed state transition > ------------------------ > > Key: HELIX-56 > URL: https://issues.apache.org/jira/browse/HELIX-56 > Project: Apache Helix > Issue Type: Task > Affects Versions: 0.6.0-incubating > Reporter: kishore gopalakrishna > > The requirement from Puneet > I wanted to know how to implement a specific state machine requirement in > Helix. > Lets say a partition is in the state S2. > 1. On an instance hosting it going down, the partition moves to state > S3 (but stays on the same instance). > 2. If the instance comes back up before a timeout expires, the > partition moves to state S1 (stays on the same instance). > 3. If the instance does not come back up before the timeout expiry, > the partition moves to state S0 (the initial state, on a different > instance picked up by the controller). > I have a few questions. > 1. I believe in order to implement Requirement 1, I have to use the > CUSTOM rebalancing feature (as otherwise the partitions will get > assigned to a new node). > The wiki page says the following about the CUSTOM mode. > "Applications will have to implement an interface that Helix will > invoke when the cluster state changes. Within this callback, the > application can recompute the partition assignment mapping" > Which interface does one have to implement ? I am assuming the > callbacks are triggered inside the controller. > 2. The transition from S2 -> S3 should not issue a callback on the > participant (instance) holding that partition. This is because the > participant is unavailable and so cannot execute the callback. Is this > doable ? > 3. One way the time-out (Requirement 3) can be implemented is to > occasionally trigger IdealState calculation after a time-out and not > only on liveness changes. Does that sound doable ? -- This message was sent by Atlassian JIRA (v6.3.4#6332)