helix-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vinayak Borkar <vbo...@yahoo.com>
Subject Re: State transitions of partitions
Date Thu, 28 Feb 2013 00:42:17 GMT

As always, thanks for the prompt response.

On 2/27/13 10:53 AM, kishore g wrote:
> Hi Vinayak,
> By default, a transition is not time bound(it can be a short one or really
> long), you can do the data movement as part of the transition and return
> from the transition after its complete.

It looks like I can run long-running transitions in this call itself 
unlike traditional event based systems where the event callback needs to 
hand over long running tasks to a separate worker. Furthermore, it looks 
like if the transition function throws an Exception, the server treats 
it as a transition failure so the controller can react to that. This is 
perfect! One question - what is the best way to propagate the exception 
to the controller so that the Controller can take different actions 
based on different kinds of problems (transient issues vs. more 
permanent errors, for e.g.).

> Lets say you have some transition called STARTED-BOOTSTRAPPED where you
> copy the data. And say you have 100 nodes in the cluster that needs to go
> from STARTED-BOOTSTRAPED. You can simply set the end state of system like
> ...
> ....

Talking about STARTED/BOOTSTRAPPED, I noticed that the builtin 
MasterSlave StateModel has a transition from OFFLINE to DROPPED, but 
there is no corresponding transition for bringing on a fresh dataset 

For example, imagine the case where a new dataset is created and 
installed as a resource. Every participant who will store a partition of 
that dataset will see an OFFLINE->SLAVE transition and then possibly a 
SLAVE->MASTER transition for the masters. However, what is the best way 
to differentiate between the initial on-boarding of a dataset and the 
case where a dataset partition is being moved to a participant. In both 
cases the participant sees the same transition I think.


View raw message