On 15-May-14 1:25 PM, minhchau wrote:
> 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.
>
So are you going to re-float the patch.
Please restrict changes to 80 characters per line.
Thanks,
Praveen
> 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
