Kishore, 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 N1:BOOTSTRAPPED N2:BOOTSTRAPPED ... .... N100:BOOTSTRAPED
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 partition.
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.
Thanks, Vinayak
