Hi Hung, Neither I have a better solution to this.
Good work. Ack from me. Thanks, Zoran From: Hung Nguyen [mailto:[email protected]] Sent: Friday, May 13, 2016 4:23 PM To: Zoran Milinkovic; [email protected] Cc: [email protected] Subject: Re: [PATCH 1 of 1] imm: Dont verify mDying on veterans when finalizing sync [#1820] Hi Zoran, For now I can't think of any better solution for that. But we need to get rid of the dead admo on the sync client. If you do the test described in the ticket and check the admo on all the nodes # immadm -O display -p resource:SA_STRING_T:adminowners opensafImm=opensafImm,safApp=safImmService you will see the dead admo is still there on the sync client but not in coord and veterans. That's a dangerous inconsistency. BR, Hung Nguyen - DEK Technologies -------------------------------------------------------------------------------- From: Zoran Milinkovic [email protected]<mailto:[email protected]> Sent: Friday, May 13, 2016 9:17PM To: Hung Nguyen, Neelakanta Reddy [email protected]<mailto:[email protected]>, [email protected]<mailto:[email protected]> Cc: Opensaf-devel [email protected]<mailto:[email protected]> Subject: RE: [PATCH 1 of 1] imm: Dont verify mDying on veterans when finalizing sync [#1820] Hi Hung, The patch looks good, but I have some concerns regarding the resending admo hard finalize message. If for example we have a cluster of 50 nodes, and more nodes are going to be synced at once. In this case, it means that more admo hard finalize messages will be broadcasted. Thanks, Zoran -----Original Message----- From: Hung Nguyen [mailto:[email protected]] Sent: Friday, May 13, 2016 2:34 PM To: Zoran Milinkovic; [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]> Subject: [PATCH 1 of 1] imm: Dont verify mDying on veterans when finalizing sync [#1820] osaf/services/saf/immsv/immnd/ImmModel.cc | 30 +++++++++--------------------- osaf/services/saf/immsv/immnd/immnd_evt.c | 18 ++++++++++++++++++ 2 files changed, 27 insertions(+), 21 deletions(-) Dont verify mDying on veterans when finalizing sync. Also if we receive ADMO_HARD_FINALIZE msg when mSyncFinalizing==true, we have to finalize that admo on the sync-client. If not there will be inconsistency between IMMNDs. diff --git a/osaf/services/saf/immsv/immnd/ImmModel.cc b/osaf/services/saf/immsv/immnd/ImmModel.cc --- a/osaf/services/saf/immsv/immnd/ImmModel.cc +++ b/osaf/services/saf/immsv/immnd/ImmModel.cc @@ -18674,23 +18674,10 @@ ImmModel::finalizeSync(ImmsvOmFinalizeSy //verify currently existing AdminOwners. + /* We can't remove the dying ROF==FALSE admo before verifying. + * There may be ROF=FALSE admo marked as dying when coord is + * generating the sync-finalize message. */ AdminOwnerVector::iterator i2; - for(i2=sOwnerVector.begin(); i2!=sOwnerVector.end();) { - if((*i2)->mDying && !((*i2)->mReleaseOnFinalize)) { - LOG_WA("Removing admin owner %u %s (ROF==FALSE) which is in demise, " - "BEFORE receiving sync/verify message", - (*i2)->mId, - (*i2)->mAdminOwnerName.c_str()); - osafassert(adminOwnerDelete((*i2)->mId, true) == SA_AIS_OK); - //lookup of admin owner again. - - //restart of iteration again. - i2=sOwnerVector.begin(); - } else { - ++i2; - } - } - ImmsvAdmoList* ai = req->adminOwners; for(; ai!=NULL; ai=ai->next) { int nrofTouchedObjs=0; @@ -18717,11 +18704,12 @@ ImmModel::finalizeSync(ImmsvOmFinalizeSy } if(info->mDying != ai->isDying) { - LOG_ER("Sync-verify: Established node has " + LOG_WA("Sync-verify: Established node has " "different isDying flag (%u) for AdminOwner " "%s, should be %u.", info->mDying, ownerName.c_str(), ai->isDying); - abort(); + /* We don't abort here because mDying can be set on veterans + * when coord is generating sync-finalize message. */ } if(info->mReleaseOnFinalize != ai->releaseOnFinalize) { LOG_ER("Sync-verify: Established node has " @@ -18754,11 +18742,11 @@ ImmModel::finalizeSync(ImmsvOmFinalizeSy } } + /* Removing all dying admo, both ROF=TRUE and ROF=FALSE */ for(i2=sOwnerVector.begin(); i2!=sOwnerVector.end();) { if((*i2)->mDying) { - osafassert((*i2)->mReleaseOnFinalize); - LOG_WA("Removing admin owner %u %s (ROF==TRUE) which is in demise, " - "AFTER receiving sync/verify message", + LOG_WA("Removing admin owner %u %s which is in demise, " + "AFTER receiving sync/verify message", (*i2)->mId, (*i2)->mAdminOwnerName.c_str()); osafassert(adminOwnerDelete((*i2)->mId, true) == SA_AIS_OK); diff --git a/osaf/services/saf/immsv/immnd/immnd_evt.c b/osaf/services/saf/immsv/immnd/immnd_evt.c --- a/osaf/services/saf/immsv/immnd/immnd_evt.c +++ b/osaf/services/saf/immsv/immnd/immnd_evt.c @@ -9817,6 +9817,24 @@ void immnd_evt_proc_admo_hard_finalize(I TRACE("Failed in hard remove of admin owner %u. Preload?", evt->info.admFinReq.adm_owner_id); } } + + /* If we receive admo hard finalize in the gap between sending sync-finalize message and + * receiving it back from fevs (mSyncFinalizing == true), we need to re-broadcast the message again. + * The sync-clients need this re-broadcasted message because + * the dead admo are included in sync-finalize message. + * The coord (this) and veterans will also recevie this as duplicated message + * but they will just drop it as the admo id can't be found. */ + if (cb->mSyncFinalizing) { + IMMSV_EVT send_evt; + memset(&send_evt, '\0', sizeof(IMMSV_EVT)); + send_evt.type = IMMSV_EVT_TYPE_IMMD; + send_evt.info.immd.type = IMMD_EVT_ND2D_ADMO_HARD_FINALIZE; + send_evt.info.immd.info.admoId = evt->info.admFinReq.adm_owner_id; + if(immnd_mds_msg_send(cb, NCSMDS_SVC_ID_IMMD, cb->immd_mdest_id, &send_evt) != NCSCC_RC_SUCCESS) { + LOG_ER("Failure to broadcast discard admo id:%u ", evt->info.admFinReq.adm_owner_id); + } + } + TRACE_LEAVE(); } ------------------------------------------------------------------------------ Mobile security can be enabling, not merely restricting. Employees who bring their own devices (BYOD) to work are irked by the imposition of MDM restrictions. Mobile Device Manager Plus allows you to control only the apps on BYO-devices by containerizing them, leaving personal data untouched! https://ad.doubleclick.net/ddm/clk/304595813;131938128;j _______________________________________________ Opensaf-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensaf-devel
