You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stratos.apache.org by Reka Thirunavukkarasu <re...@wso2.com> on 2014/10/24 12:41:08 UTC

[Grouping][Part-2] Handling termination Behaviour in Composite Application Monitor Hierarchy

Hi

This is to discuss about $subject. As we have identified from earlier
discussion that the termination behaviour can considered for
application/group as below:

*terminate-none* : none of them will be returned

*teminate-all*: all the children of a particular group will be terminated.

*terminate-dependent*: all the children which has dependency to the faulty
sibling of that particular group will be terminated.

After we decide on the termination list of nodes, we can terminate them in
one of the following order.

1. Terminate all of them in parallel *[Default behaviour]*
2. Reverse order of the startup order of those nodes
3. Terminate them using the startup order
4. Any other order which we need to consider???

Once confirmed that all of the nodes in the termination list are
terminated, the relevant monitor will bring them up using the startup order
again.

How Termination of a child works in the Monitor hierarchy
----------------------------------------------------------------------------

Assumption: Application is Active and one of the member suddenly goes
faulty.

When a cluster becomes inActive due to minimum rule is not satisfied as one
of the member is faulty, the state of the cluster will be changed to *inActive
*from* Active *and the status change will notify its parent. So if the
parent has any dependent for the *inActive* node, then it will try to
terminate the dependents. Like wise, the termination of one node will be
propagated to their parents. The parents will behave according to their
specified termination behaviours. Once this propagation stops at a level
where it has *terminate-none or eventually reaches the top application
level, *then all sub groups will get to terminated according to the
termination behaviour. Once sub groups are terminated, then the respective
top Group/Application monitor which tends to terminate the sub groups, will
bring all the terminated groups/clusters using startup order again.

We are currently implementing termination behaviour by considering
only the *default
case*. Due to the complexity of the case 2 and 3, we need to come up with a
good proposal to plug it in the current architecture. Will work on that as
time permits and update on it...

Please share your thoughts on this....

FYI: node means a group/cluster in the Application.

Thanks,
Reka


-- 
Reka Thirunavukkarasu
Senior Software Engineer,
WSO2, Inc.:http://wso2.com,
Mobile: +94776442007