I was thinking if during su instantiation, a number of component are
instantiated while the others are in middle of "instantiating". At that
moment some faulty components are restarted and escalate to su restart.
Personally I don't want the "instantiating" components get restarted so
I added to the patch to avoid restart the instantiating components.
But actually the "instantiating" components will not get restarted in
this situation, because su is still also "instantiating" and amfnd is
doing nothing if receiving "restart" event in "instantiating" state.
I will remove this patch the check for "instantiating" component, and
probably comment along the code to remind "instantiating" component
should be considered when avnd_su_pres_insting_surestart_hdler is
implemented.
BR/Minh
On 5/15/2014 4:02 PM, praveen malviya wrote:
>
> On 15-May-14 6:21 AM, Minh Hon Chau wrote:
>> osaf/services/saf/amf/amfnd/susm.cc | 7 +++++--
>> 1 files changed, 5 insertions(+), 2 deletions(-)
>>
>>
>> Problem: In case of npi su restart recovery, the condition to change
>> su presence
>> state is not sufficient. If the component of the last csi in csi_list
>> has been
>> restarted first due to componentRestart (before suRestart), amfnd can
>> not find
>> any next csi and changes the su presence state to INSTANTIATED, this
>> will miss
>> the restart for the rest of components.
>>
>> Change: This version (v2) uses UNASSIGNED csi (instead of marking all
>> components
>> FAILED as in first version) to avoid duplication of restarting the
>> same component
>> many times during su restart, only component linked to UNASSIGNED
>> csi is restarted.
>> Therefore, the condition of changing su presence state to
>> INSTANTIATED should be
>> all csis are ASSIGNED
>>
>> diff --git a/osaf/services/saf/amf/amfnd/susm.cc
>> b/osaf/services/saf/amf/amfnd/susm.cc
>> --- a/osaf/services/saf/amf/amfnd/susm.cc
>> +++ b/osaf/services/saf/amf/amfnd/susm.cc
>> @@ -2637,12 +2637,15 @@ uint32_t avnd_su_pres_restart_compinst_h
>> /* get the next csi */
>> curr_csi = (AVND_COMP_CSI_REC
>> *)m_NCS_DBLIST_FIND_NEXT(&curr_csi->si_dll_node);
>> - if (curr_csi) {
>> + if (curr_csi &&
>> + m_AVND_COMP_CSI_CURR_ASSIGN_STATE_IS_UNASSIGNED(curr_csi) && /*
>> avoid restarting the already-restarted comp */
>> + curr_csi->comp->pres != SA_AMF_PRESENCE_RESTARTING && /*
>> avoid restarting the comp just coming into componentRestart recovery */
>> + curr_csi->comp->pres != SA_AMF_PRESENCE_INSTANTIATING) {
>> /* avoid restarting the comp in progress of instantiation */
> Why check for "Instantiating" state has been included here. In both
> component restart and su restart recovery policy, a component never
> enters into INSTANTIATING presence state. It was not in the first
> version of this patch and discussions followed on it.
>
> Thanks
> Praveen
>> /* we have another csi. trigger the comp fsm with
>> RestartEv */
>> rc = avnd_comp_clc_fsm_trigger(cb, curr_csi->comp,
>> AVND_COMP_CLC_PRES_FSM_EV_RESTART);
>> if (NCSCC_RC_SUCCESS != rc)
>> goto done;
>> - } else {
>> + } else if (all_csis_in_assigned_state(su)) {
>> /* => si assignment done */
>> avnd_su_pres_state_set(su, SA_AMF_PRESENCE_INSTANTIATED);
>> }
>
>
------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
Opensaf-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensaf-devel
