Hi, I think, as of now, approaches discussed in this mail thread can be mixed for a temporary solution: Dispatch() can return SA_AIS_OK by invoking the callback(s) with truncated values for any long field (like comp name, csi name etc). In this way comp will have callbacks and AMF will also be maintaining legal COMPCSIs. Actual values can be logged. Also the the PR doc and Readme should talk how truncation will be performed. I think, this can be done in this release. Other solution of rejecting the CCB itself can be postponed as of now.
Thanks, Praveen On 11-Aug-16 10:03 AM, Long Nguyen wrote: > Hi Praveen and others, > > I have an idea marked with [Long] below. > > Best regards, > Long Nguyen. > > On 8/3/2016 1:45 PM, praveen malviya wrote: >> >> >> On 02-Aug-16 3:39 AM, minh chau wrote: >>> Hi Praveen, >>> >>> One comment with [Minh] in line. >>> >>> Thanks, >>> Minh >>> >>> On 01/08/16 17:22, Gary Lee wrote: >>>> Hi Praveen >>>> >>>> On 1/08/2016 4:29 PM, praveen malviya wrote: >>>>> Hi Gary, Long, >>>>> >>>>> Some comments/observations: >>>>> -In AMFD saAisNameBorrow() is used in logging and AMFND uses >>>>> osaf_extended_name_borrow(). >>>>> For osaf_extended_name_borrow() note in osaf_extended_name.h says it >>>>> is intended for mainly agent libraries. But middle-ware services >>>>> always use core libs. At the same time saAisNameBorrow(), I think, is >>>>> for application. >>>>> any reason of using them this way and what is the recommended way? >>>> I think I used both styles in amfd. I think we can change saAisNameXX >>>> to osaf_extended_name_XX just before pushing, to make it consistent >>>> with the rest of the OpenSAF services. >>>>> -I think, one case may arrive from upgrade perspective. >>>>> Suppose any application (say amf_demo app) is running without >>>>> enabling long dn and a csi, with its RDn greater than 256, is added >>>>> dynamically (long dn enabled in IMM). In this case AMFD will assign >>>>> this csi to the running component. Component will not be able to read >>>>> the CSI and may crash. >>>>> This is related to invocation of CSI_SET callback but same will be >>>>> valid for PG tracking also. There may be other cases also. >>>>> Even truncation will not work in this case. >>> [Minh] I think the agent patch that Gary submitted currently returns >>> SA_AIS_ERR_NAME_TOO_LONG in saAmfDispatch() if long DN callback comes to >>> legacy application (unadapted long DN app). The real callback won't be >>> issued but application may crash if it exit() on non-SA_AIS_OK from >>> Dispatch(). I guess you have seen this with #1553? Do you think it's >>> good way if amf agent drops the long DN callback and also Dispatch() >>> returns OK to legacy app, and print error in syslog? >> Not observed in the context of #1553, but I remember about such a fix >> in NTF long dn changes. >> Returning SA_AIS_OK in Dispatch() call saves application from crash, >> but the problem in AMF is still different as it will maintain a >> COMPCSI relationship without comp being actually assigned for that. >> >> Can we think of a way where AMF will not allow this conf change by >> rejecting the CCB operation itself. For this AMF should know that this >> application supports Long dn or not. But this information needs to be >> carried from agent to AMFD. >> Before going for such a way, I think, we can ask opinion from other >> AMF maintainers. >> [Long] You have the good solution. However, it is hard to know if an >> application supports long DN or not at the time of CCB operration. Can >> we make your suggestion as an enhancement later? >> >> Thanks, >> Praveen >> >> >> >>>>> - While running some tests observed crashes in amfnd and amfd. >>>>> I will update #1642 with bt information. >>>> Minh will answer this bit. >>>> >>>> Thanks >>>> Gary >>>> >>> >> > ------------------------------------------------------------------------------ What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. http://sdm.link/zohodev2dev _______________________________________________ Opensaf-devel mailing list Opensaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-devel
