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
