Hi Neel, Currently I have to NACK this.
I dont understand the problem description nor the solution patch for this ticket. When an attempt is made to become a class/object implementer/applier then there must not be any in-progress CCB for the objects-of-the-class/the-object. The reason is that the newly attached implementer/applier would not get operation callbacks for operations done prior to the attachement. So that guard has nothing to do with the particular implementer/applier attaching. It is a general rule that they must attach when the class/object is "idle" in ccb terms. This so they either miss seing the CCB or see the complete CCB. In principle one could contemplate a solution where freshly attached implementers/appliers Triggered a re-send from the IMMND of relevant callbacks the the late-arriving oi/applier missed. But that is a complex solution for a rare and non-realtime sensitive problem. /AndersBj When an attempt is made to become a class/object implementer/applier then there must not be any in-progress CCB for the objects-of-the-class/object. The reason is that the newly attached implementer/applier would not get operation callbacks for operations done prior to the attachement. So this guard has nothing to do with the particular implementer/applier attaching. It is a general rule that they must attach when the class/object is "idle" in ccb terms. /AndersBj -----Original Message----- From: [email protected] [mailto:[email protected]] Sent: den 17 september 2014 14:06 To: Anders Björnerstedt; Zoran Milinkovic Cc: [email protected] Subject: [PATCH 1 of 1] imm: Return TRY_AGAIN only when object apllier matches the Re-using implementerset info[ #1078] osaf/services/saf/immsv/immnd/ImmModel.cc | 13 ++++++++----- 1 files changed, 8 insertions(+), 5 deletions(-) Presently if the active ccb object contains an object-applier TRY_AGAIN is returned.The solution is when implementerset is called activeccbs are checked, return TRY_AGAIN only when the object apllier has same implementer info as the newly connected implementer. 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 @@ -12302,11 +12302,14 @@ ImmModel::implementerSet(const IMMSV_OCT ismIter = sObjAppliersMap.find(omit->first); if(ismIter != sObjAppliersMap.end()) { - TRACE("TRY_AGAIN: ccb %u is active on object '%s' " - "bound to object applier '%s'. Can not re-attach applier", - ccb->mId, omit->first.c_str(), implName.c_str()); - err = SA_AIS_ERR_TRY_AGAIN; - goto done; + ImplementerSet *implSet = ismIter->second; + if(implSet->find(info) != implSet->end()) { + TRACE("TRY_AGAIN: ccb %u is active on object '%s' " + "bound to object applier '%s'. Can not re-attach applier", + ccb->mId, omit->first.c_str(), implName.c_str()); + err = SA_AIS_ERR_TRY_AGAIN; + goto done; + } } } } ------------------------------------------------------------------------------ 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
