Hi AndersBj, If there is an active ccb, the object has obj-applier. If an attempt is made to (implementer)set an applier then TRY_AGAIN is returned without checking the newly connected implementer is intrested in the ongoing ccb-obj or obj-applier. Eg:
ep 15 9:38:45.447989 osafimmnd [2340:ImmModel.cc:12117] >> implementerSet Sep 15 9:38:45.448038 osafimmnd [2340:ImmModel.cc:12158] T7 Re-using implementer for @safAmfService2020f Sep 15 9:38:45.448091 osafimmnd [2340:ImmModel.cc:12201] TR TRY_AGAIN: ccb 27 is active on object 'attrName_testMA_verifyObjApplRejModifyCallback_101' bound to object applier '@safAmfService2020f'. Can not re-attach applier Sep 15 9:38:45.448129 osafimmnd [2340:ImmModel.cc:12303] << implementerSet In the above case newly connected applier "@safAmfService2020f" is no-way intrested in application object(attrName_testMA_verifyObjApplRejModifyCallback_101) and its obj-applier. If there is an active ccb and the active ccb-object has object applier TRY_AGAIN is returned whic may not be correct. The problems occurs when either the application clears and re-connects (as in AMFD case) or exits and connects again. TRY_AGAIN must be returned only when attempted applier is interested in the on going CCB-object applier. At the implementerSet stage one cannot know on which class/object does the newly connected applier is interested. The patch published for this ticket, returns TRY_AGAIN only when the newly attached applier is the on-going CCB-object applier(this occurs only when the applier is re-connected or cleared and connected again). /Neel. On Wednesday 17 September 2014 06:49 PM, Anders Björnerstedt wrote: > 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
