Yeah, It seems when the orignial testing that resulted in #1059 was repeated, it produced a different result, i.e. CLM recieved a BAD_OPER first, and subsequently BAD_HANDLE(1067). Neel had analysed the logs and concluded that the BAD_OPER was because of 1057.
Thanks, Mathi. ----- [email protected] wrote: > I am currently working on ticket #1057 which displays a set of 2PBE > issues. > But I dont see how any of those issues could lead to BAD_OPERATION ? > > I see in the ticket one case where ClassImplementerSet gets error code > 9, which > is BAD_HANLDE not BAD_OPERATION. > > Do you really mean BAD_OPERATION ? > That error code for saImmOiClassImplementerSet has only one > meaning/case: > The class-name is a runtime-class, not a config-class. > > /AndersBj > > -----Original Message----- > From: [email protected] [mailto:[email protected]] > Sent: den 12 september 2014 21:05 > To: [email protected] > Cc: [email protected] > Subject: [devel] [PATCH 1 of 1] clm: imm reinit mechanism shall check > for impl_set flag in BAD_OPER scenarios [#1067] > > osaf/services/saf/clmsv/clms/clms_imm.c | 10 +++++++++- > 1 files changed, 9 insertions(+), 1 deletions(-) > > > It is possible that IMM (probably because of 1057) returns BAD_OPER. > This requires hardening of the CLM imm reinit mechanism when error > such as BAD_OPER is returned. > As a part of admin-state updates, clm need to check for impl_set flag > before attempting rtobject update. > > diff --git a/osaf/services/saf/clmsv/clms/clms_imm.c > b/osaf/services/saf/clmsv/clms/clms_imm.c > --- a/osaf/services/saf/clmsv/clms/clms_imm.c > +++ b/osaf/services/saf/clmsv/clms/clms_imm.c > @@ -449,12 +449,20 @@ void clms_admin_state_update_rattr(CLMS_ > TRACE_ENTER2("Admin state %d update for node %s", nd->admin_state, > nd->node_name.value); > > CLMS_CLUSTER_NODE *node = NULL; > - /* If this update was attempted was for a node down and as a part of > try-again-later, then > + /* If this update being attempted was for a node down and as a part > of > +try-again-later, then > * we need to lookup using name, because the node_id record would > * have been deleted as a part of node down processing > */ > osafassert((node = clms_node_get_by_name(&nd->node_name))); > > + if (clms_cb->is_impl_set == false) { > + TRACE("Implementer not yet set: Switching on the tryagain > flag"); > + node->rtu_pending = true; > + clms_cb->rtu_pending = true; > + TRACE_LEAVE(); > + return; > + } > + > SaImmAttrValueT attrUpdateValue[] = { &nd->admin_state }; > const SaImmAttrModificationT_2 *attrMods[] = { > &attr_Mod[0], > > ------------------------------------------------------------------------------ > Want excitement? > Manually upgrade your production database. > When you want reliability, choose Perforce Perforce version control. > Predictably reliable. > http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk > _______________________________________________ > Opensaf-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/opensaf-devel ------------------------------------------------------------------------------ Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk _______________________________________________ Opensaf-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensaf-devel
