Re: [devel] [PATCH 0 of 3] Review Request for lgsv: Log Service CLM integration [#1638] V1
Hi! Some comments: 1) Have you considered using std::map instead of adding a new instance of NCS_PATRICIA_TREE? 2) At least when adding completely new files (lgs_clm.cc in this case), could you try to keep them "clean" from cppcheck and cpplint warnings (i.e. make sure there are no warnings in newly added files)? 3) You have added the new file lgs_clm.cc, but there is no corresponding lgs_clm.h header file. Could you also add the file lgs_clm.h and put the public API of lgs_clm.cc in it? 4) lgs_clm.cc has only one single #include statement, which includes "lgs.h". But it uses many interfaces that are not declared in lgs.h. You should not rely on header files being indirectly included from other header files. lgs_clm.cc ought to include all headers that it needs, for example: "saClm.h" for the CLM API, for uint32_t et.al., "logtrace.h" for the OpenSAF trace API, for the exit() function and the EXIT_FAILURE constant, for the pthreads API. 5) Isn't the variable name usr2_sel_obj misleading? There is another variable with the very similar name usr1_sel_obj, and it is a selection object which is used when the process receives the SIGUSR1 signal. I would have expected that usr2_sel_obj would correspondingly be used when the process receives the SIGUSR2 signal. However, it seems that instead it is actually used to signal an MDS up event for AMFD. I think it ought to be renamed to reflect this. Or maybe even get rid of this selection object and instead post a message in the mailbox when we get this MDS event? 6) Why is the usr2_sel_obj created only in the case the when the LOG service is started by NID? This only makes sense for the usr1_sel_obj which is used to signal AMF instantiation when the process has already been started by NID. To me it looks like the code currently doesn't work when it is not started by NID - in this case clmSelectionObject will be initialized to -1 and stay that way forever. 7) I suppose the whole reason for triggering CLM initalization after MDS up event from AMFD, using this usr2_sel_obj variable, is to solve some circular dependency problem. But is it at all needed when CLM initialization is taken care of in a separate thread? Wouldn't it work fine if you simply start this CLM initialization thread when you receive an AMF assignment (i.e. start the thread from inside the initialize_for_assignment() function)? Could you try it? :-) 8) In C++, please use nullptr instead of NULL and 0 (when the type is supposed to be a pointer). So e.g. clm_callbacks should have have nullptr instead if 0 in its first position, and lgs_clm_init_thread ought to return nullptr instead of NULL. thanks, Anders Widell On 07/26/2016 10:42 AM, mahesh.va...@oracle.com wrote: > Summary:lgsv: Log Service CLM integration [#1638] V1 > Review request for Trac Ticket(s): #1638 > Peer Reviewer(s): Vu, Lennart > Pull request to: <> > Affected branch(es): Default > Development branch: Default > > > Impacted area Impact y/n > > Docsn > Build systemn > RPM/packaging n > Configuration files n > Startup scripts n > SAF servicesy > OpenSAF servicesn > Core libraries n > Samples n > Tests n > Other n > > > Comments (indicate scope for each "y" above): > - > > changeset 0637f0bfc39b5173776b3cdca088cffd28425432 > Author: A V Mahesh > Date: Tue, 26 Jul 2016 14:07:35 +0530 > > lga: agent Cluster Membership (CLM) integration [#1638] V1 Description: > > Form CLM integration is supported from Log Service A.02.02. > > At-least a A.02.02 LGA client will check CLM membership status of > client's > node. old LGA clients A.02.01 are always clm member. > > This patch enhanced the log service for Unavailability of the Log > Service > API on a Non-Member Node which will fail with SA_AIS_ERR_UNAVAILABLE. > > After this patch the Log Service does not provide service to processes > on > cluster nodes that are not in the cluster membership. > > If the node rejoins the cluster membership, processes executing on the > node > will be able to reinitialize new library handles and use the entire set > of > Log Service APIs that operate on these new handles; however, invocation > of > APIs that operate on handles acquired by any process before the node > left > the membership will continue to fail with SA_AIS_ERR_UNAVAILABLE (or > with > the special treatment described above for asynchronous calls) with the > exception of saLogFinalize(), which is used to free the library handles > and > all resources associated with these handles. Hence, it is recommended > for > the processes to finalize the library handles as soon as the proce
Re: [devel] [PATCH 4 of 5] imm: Added the updated OpensafImm class [#195]
The patch 4 of 5 is not complete, as forgot to add the new_file useful at the time of upgrade. Attaching the patch 4 of 5 with new_file. Regards, Neel. On 2016/07/27 02:01 PM, reddy.neelaka...@oracle.com wrote: tests/immsv/management/test_saImmOmAccessorGet_2.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/tests/immsv/management/test_saImmOmAccessorGet_2.c b/tests/immsv/management/test_saImmOmAccessorGet_2.c --- a/tests/immsv/management/test_saImmOmAccessorGet_2.c +++ b/tests/immsv/management/test_saImmOmAccessorGet_2.c @@ -133,7 +133,7 @@ void saImmOmAccessorGet_2_04(void) rc = saImmOmAccessorGet_2(accessorHandle, &objectName, accessorGetConfigAttrsToken, &attributes); /* Verify the number of config attributes */ cnt = print_SaImmAttrValuesT_2(attributes); -assert(cnt == 8); +assert(cnt == 12); test_validate(rc, SA_AIS_OK); safassert(saImmOmFinalize(immOmHandle), SA_AIS_OK); } -- 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 diff --git a/samples/immsv/OpensafImm_Upgrade_5.1.xml b/samples/immsv/OpensafImm_Upgrade_5.1.xml new file mode 100644 --- /dev/null +++ b/samples/immsv/OpensafImm_Upgrade_5.1.xml @@ -0,0 +1,113 @@ + +http://www.w3.org/2001/XMLSchema-instance"; xsi:noNamespaceSchemaLocation="SAI-AIS-IMM-XSD-A.02.13.xsd" xmlns:xs="http://www.w3.org/2001/XMLSchema"; xmlns:imm="http://www.saforum.org/IMMSchema";> + +SA_CONFIG + + opensafImm + SA_NAME_T + SA_CONFIG + SA_INITIALIZED + + + maxClasses + SA_UINT32_T + SA_CONFIG + SA_WRITABLE + 1000 + + + maxImplementers + SA_UINT32_T + SA_CONFIG + SA_WRITABLE + 3000 + + + maxAdminowners + SA_UINT32_T + SA_CONFIG + SA_WRITABLE + 2000 + + + maxCcbs + SA_UINT32_T + SA_CONFIG + SA_WRITABLE + 1 + + + scAbsenceAllowed + SA_UINT32_T + SA_RUNTIME + SA_PERSISTENT + SA_CACHED + 0 + + + accessControlMode + SA_UINT32_T + SA_CONFIG + SA_WRITABLE + 0 + + + authorizedGroup + SA_STRING_T + SA_CONFIG + SA_WRITABLE + + + longDnsAllowed + SA_UINT32_T + SA_CONFIG + SA_WRITABLE + 0 + + + opensafImmSyncBatchSize + SA_UINT32_T + SA_CONFIG + SA_WRITABLE + 65223 + + + opensafImmNostdFlags + SA_UINT32_T + SA_RUNTIME + SA_CACHED + 0 + + + opensafImmEpoch + SA_UINT32_T + SA_RUNTIME + SA_PERSISTENT + SA_CACHED + + + opensafImmClassNames + SA_STRING_T + SA_RUNTIME + SA_MULTI_VALUE + SA_PERSISTENT + SA_CACHED + + + SaImmAttrImplementerName + SA_STRING_T + SA_CONFIG + + + SaImmAttrClassName + SA_STRING_T + SA_CONFIG + OpensafImm + + + SaImmAttrAdminOwnerName + SA_STRING_T + SA_CONFIG + + + diff --git a/tests/immsv/management/test_saImmOmAccessorGet_2.c b/tests/immsv/management/test_saImmOmAccessorGet_2.c --- a/tests/immsv/management/test_saImmOmAccessorGet_2.c +++ b/tests/immsv/management/test_saImmOmAccessorGet_2.c @@ -133,7 +133,7 @@ void saImmOmAccessorGet_2_04(void) rc = saImmOmAccessorGet_2(accessorHandle, &objectName, accessorGetConfigAttrsToken, &attributes); /* Verify the number of config attributes */ cnt = print_SaImmAttrValuesT_2(attributes); -assert(cnt == 8); +assert(cnt == 12); test_validate(rc, SA_AIS_OK); safassert(saImmOmFinalize(immOmHandle), SA_AIS_OK); } -- 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
Re: [devel] [PATCH 0 of 1] Review Request for imm: Fix memory leak in saImmOmCcbObjectRead [#1927]
Hi Hung, Reviewed the patch. Ack. /Neel. On 2016/07/21 03:19 PM, Hung Nguyen wrote: > Summary: imm: Fix memory leak in saImmOmCcbObjectRead [#1927] > Review request for Trac Ticket(s): 1927 > Peer Reviewer(s): Zoran, Neel > Pull request to: > Affected branch(es): 5.0, 5.1 > Development branch: 5.1 > > > Impacted area Impact y/n > > Docsn > Build systemn > RPM/packaging n > Configuration files n > Startup scripts n > SAF servicesy > OpenSAF servicesn > Core libraries n > Samples n > Tests n > Other n > > > Comments (indicate scope for each "y" above): > - > > > changeset 097ec0d098d9cf5d861addecea5c3184d3b7261d > Author: Hung Nguyen > Date: Thu, 21 Jul 2016 16:47:18 +0700 > > imm: Fix memory leak in saImmOmCcbObjectRead [#1927] > > Fix memory leak in saImmOmCcbObjectRead. > > > Complete diffstat: > -- > osaf/libs/agents/saf/imma/imma_om_api.c | 6 ++ > 1 files changed, 6 insertions(+), 0 deletions(-) > > > Testing Commands: > - > > > > Testing, Expected Results: > -- > valgrind --leak-check=full --track-origins=yes immomtest 6 74 > > > Conditions of Submission: > - > Ack from reviewers. > > > Arch Built StartedLinux distro > --- > mipsn n > mips64 n n > x86 n n > x86_64 n n > powerpc n n > powerpc64 n n > > > Reviewer Checklist: > --- > [Submitters: make sure that your review doesn't trigger any checkmarks!] > > > Your checkin has not passed review because (see checked entries): > > ___ Your RR template is generally incomplete; it has too many blank entries > that need proper data filled in. > > ___ You have failed to nominate the proper persons for review and push. > > ___ Your patches do not have proper short+long header > > ___ You have grammar/spelling in your header that is unacceptable. > > ___ You have exceeded a sensible line length in your headers/comments/text. > > ___ You have failed to put in a proper Trac Ticket # into your commits. > > ___ You have incorrectly put/left internal data in your comments/files > (i.e. internal bug tracking tool IDs, product names etc) > > ___ You have not given any evidence of testing beyond basic build tests. > Demonstrate some level of runtime or other sanity testing. > > ___ You have ^M present in some of your files. These have to be removed. > > ___ You have needlessly changed whitespace or added whitespace crimes > like trailing spaces, or spaces before tabs. > > ___ You have mixed real technical changes with whitespace and other > cosmetic code cleanup changes. These have to be separate commits. > > ___ You need to refactor your submission into logical chunks; there is > too much content into a single commit. > > ___ You have extraneous garbage in your review (merge commits etc) > > ___ You have giant attachments which should never have been sent; > Instead you should place your content in a public tree to be pulled. > > ___ You have too many commits attached to an e-mail; resend as threaded > commits, or place in a public tree for a pull. > > ___ You have resent this content multiple times without a clear indication > of what has changed between each re-send. > > ___ You have failed to adequately and individually address all of the > comments and change requests that were proposed in the initial review. > > ___ You have a misconfigured ~/.hgrc file (i.e. username, email etc) > > ___ Your computer have a badly configured date and time; confusing the > the threaded patch review. > > ___ Your changes affect IPC mechanism, and you don't present any results > for in-service upgradability test. > > ___ Your changes affect user manual and documentation, your patch series > do not contain the patch that updates the Doxygen manual. > -- 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
Re: [devel] [PATCH 1 of 1] cpsv: To update checkpoint user number for each node [#1669] V3
Dear Mahesh, Thank you very much for your provided information. I will continue investigating this problem. Sincerely, Hoang -Original Message- From: A V Mahesh [mailto:mahesh.va...@oracle.com] Sent: Wednesday, July 27, 2016 4:53 PM To: Vo Minh Hoang ; 'Nhat Pham' ; anders.wid...@ericsson.com Cc: opensaf-devel@lists.sourceforge.net Subject: Re: [PATCH 1 of 1] cpsv: To update checkpoint user number for each node [#1669] V3 Hi Hoang, I still able to reproduce the problem , some time it increments two time of current readers , some time it is getting decremented to less then zero ( variable are set (0xfff6) ) Unfortunately I don't have any specific steps order , but this issue occurs in cluster setup with 1new controller & 1 old controller and 2 old payloads when tow application opened & holded on old payloads ( don't exist) , and try to do fail-overs of controllers and then exit the applications on both payloads, you will end up with error. I broad , I suggest you look at the new messages that are getting introduced in this patch are prevented with version check === PL-3:~ # immlist safCkpt=checkpoint_test77 Name Type Value(s) safCkptSA_STRING_T safCkpt=checkpoint_test77 saCkptCheckpointUsedSize SA_UINT64_T 110 (0x6e) saCkptCheckpointSize SA_UINT64_T 2097152 (0x20) saCkptCheckpointRetDurationSA_TIME_T 9223372036854775807 (0x7fff, Sat Apr 12 05:17:16 2262) saCkptCheckpointNumWriters SA_UINT32_T 4294967286 (0xfff6) saCkptCheckpointNumSectionsSA_UINT32_T 1 (0x1) saCkptCheckpointNumReplicasSA_UINT32_T 2 (0x2) saCkptCheckpointNumReaders SA_UINT32_T 4294967286 (0xfff6) saCkptCheckpointNumOpeners SA_UINT32_T 0 (0x0) saCkptCheckpointNumCorruptSections SA_UINT32_T 0 (0x0) saCkptCheckpointMaxSectionsSA_UINT32_T 1 (0x1) saCkptCheckpointMaxSectionSize SA_UINT64_T 2097152 (0x20) saCkptCheckpointMaxSectionIdSize SA_UINT64_T 256 (0x100) *saCkptCheckpointCreationTimestamp SA_TIME_T 14696097540 (0x14651a48f19e8400, Wed Jul 27 14:25:54 2016)* saCkptCheckpointCreationFlags SA_UINT32_T 2 (0x2) SaImmAttrImplementerName SA_STRING_T safCheckPointService SaImmAttrClassName SA_STRING_T SaCkptCheckpoint SaImmAttrAdminOwnerNameSA_STRING_T SC-2:~ # immlist safCkpt=checkpoint_test77 Name Type Value(s) safCkptSA_STRING_T safCkpt=checkpoint_test77 saCkptCheckpointUsedSize SA_UINT64_T 110 (0x6e) saCkptCheckpointSize SA_UINT64_T 2097152 (0x20) saCkptCheckpointRetDurationSA_TIME_T 9223372036854775807 (0x7fff, Sat Apr 12 05:17:16 2262) saCkptCheckpointNumWriters SA_UINT32_T 20 (0x14) saCkptCheckpointNumSectionsSA_UINT32_T 1 (0x1) saCkptCheckpointNumReplicasSA_UINT32_T 2 (0x2) saCkptCheckpointNumReaders SA_UINT32_T 20 (0x14) saCkptCheckpointNumOpeners SA_UINT32_T 20 (0x14) saCkptCheckpointNumCorruptSections SA_UINT32_T 0 (0x0) saCkptCheckpointMaxSectionsSA_UINT32_T 1 (0x1) saCkptCheckpointMaxSectionSize SA_UINT64_T 2097152 (0x20) saCkptCheckpointMaxSectionIdSize SA_UINT64_T 256 (0x100) *saCkptCheckpointCreationTimestamp SA_TIME_T 14696106140 (0x14651b112d9d1c00, Wed Jul 27 14:40:14 2016)* saCkptCheckpointCreationFlags SA_UINT32_T 2 (0x2) SaImmAttrImplementerName SA_STRING_T safCheckPointService SaImmAttrClassName SA_STRING_T SaCkptCheckpoint SaImmAttrAdminOwnerNameSA_STRING_T === -AVM On 7/26/2016 8:41 AM, Vo Minh Hoang wrote: > Dear Mahesh, > > Thank you very much for your checking. > > Unfortunately, I unsuccessfully reproduce this problem in our environment. > Would you please send us the trace log of d and nd of both SC-1 and > SC-2 when error occur for investigating. >
Re: [devel] [PATCH 1 of 1] cpsv: To update checkpoint user number for each node [#1669] V3
Hi Hoang, I still able to reproduce the problem , some time it increments two time of current readers , some time it is getting decremented to less then zero ( variable are set (0xfff6) ) Unfortunately I don't have any specific steps order , but this issue occurs in cluster setup with 1new controller & 1 old controller and 2 old payloads when tow application opened & holded on old payloads ( don't exist) , and try to do fail-overs of controllers and then exit the applications on both payloads, you will end up with error. I broad , I suggest you look at the new messages that are getting introduced in this patch are prevented with version check === PL-3:~ # immlist safCkpt=checkpoint_test77 Name Type Value(s) safCkptSA_STRING_T safCkpt=checkpoint_test77 saCkptCheckpointUsedSize SA_UINT64_T 110 (0x6e) saCkptCheckpointSize SA_UINT64_T 2097152 (0x20) saCkptCheckpointRetDurationSA_TIME_T 9223372036854775807 (0x7fff, Sat Apr 12 05:17:16 2262) saCkptCheckpointNumWriters SA_UINT32_T 4294967286 (0xfff6) saCkptCheckpointNumSectionsSA_UINT32_T 1 (0x1) saCkptCheckpointNumReplicasSA_UINT32_T 2 (0x2) saCkptCheckpointNumReaders SA_UINT32_T 4294967286 (0xfff6) saCkptCheckpointNumOpeners SA_UINT32_T 0 (0x0) saCkptCheckpointNumCorruptSections SA_UINT32_T 0 (0x0) saCkptCheckpointMaxSectionsSA_UINT32_T 1 (0x1) saCkptCheckpointMaxSectionSize SA_UINT64_T 2097152 (0x20) saCkptCheckpointMaxSectionIdSize SA_UINT64_T 256 (0x100) *saCkptCheckpointCreationTimestamp SA_TIME_T 14696097540 (0x14651a48f19e8400, Wed Jul 27 14:25:54 2016)* saCkptCheckpointCreationFlags SA_UINT32_T 2 (0x2) SaImmAttrImplementerName SA_STRING_T safCheckPointService SaImmAttrClassName SA_STRING_T SaCkptCheckpoint SaImmAttrAdminOwnerNameSA_STRING_T SC-2:~ # immlist safCkpt=checkpoint_test77 Name Type Value(s) safCkptSA_STRING_T safCkpt=checkpoint_test77 saCkptCheckpointUsedSize SA_UINT64_T 110 (0x6e) saCkptCheckpointSize SA_UINT64_T 2097152 (0x20) saCkptCheckpointRetDurationSA_TIME_T 9223372036854775807 (0x7fff, Sat Apr 12 05:17:16 2262) saCkptCheckpointNumWriters SA_UINT32_T 20 (0x14) saCkptCheckpointNumSectionsSA_UINT32_T 1 (0x1) saCkptCheckpointNumReplicasSA_UINT32_T 2 (0x2) saCkptCheckpointNumReaders SA_UINT32_T 20 (0x14) saCkptCheckpointNumOpeners SA_UINT32_T 20 (0x14) saCkptCheckpointNumCorruptSections SA_UINT32_T 0 (0x0) saCkptCheckpointMaxSectionsSA_UINT32_T 1 (0x1) saCkptCheckpointMaxSectionSize SA_UINT64_T 2097152 (0x20) saCkptCheckpointMaxSectionIdSize SA_UINT64_T 256 (0x100) *saCkptCheckpointCreationTimestamp SA_TIME_T 14696106140 (0x14651b112d9d1c00, Wed Jul 27 14:40:14 2016)* saCkptCheckpointCreationFlags SA_UINT32_T 2 (0x2) SaImmAttrImplementerName SA_STRING_T safCheckPointService SaImmAttrClassName SA_STRING_T SaCkptCheckpoint SaImmAttrAdminOwnerNameSA_STRING_T === -AVM On 7/26/2016 8:41 AM, Vo Minh Hoang wrote: > Dear Mahesh, > > Thank you very much for your checking. > > Unfortunately, I unsuccessfully reproduce this problem in our environment. > Would you please send us the trace log of d and nd of both SC-1 and SC-2 > when error occur for investigating. > > For reference, here is my reproduce steps: > 1. prepare SC-1 with patch, SC-2 without patch > 2. create checkpoint in SC-1 > 3. open checkpoint in SC-2 > 4. immlist to get checkpoint information > 5. unlink and close checkpoint in SC-1 > 6. immlist again to confirm its deletion > 7. create checkpoint again in SC-1 > 8. list all replica in sharemem, there is a different here, in you error > log, why sharemem is different betwee
[devel] [PATCH 5 of 5] imm: updated README [#195]
osaf/services/saf/immsv/README | 43 ++ 1 files changed, 43 insertions(+), 0 deletions(-) diff --git a/osaf/services/saf/immsv/README b/osaf/services/saf/immsv/README --- a/osaf/services/saf/immsv/README +++ b/osaf/services/saf/immsv/README @@ -2846,6 +2846,49 @@ been bound on the local node by the same Applier name continues to be shared between nodes, while object and class applier bindings are kept on the originating node. +IMM Hardcoded limits as config parameters (5.1) +=== +http://sourceforge.net/p/opensaf/tickets/195/ + +The enhancemnets makes IMM limts configurable. The limits like maxClasses, +maxImplementers, maxAdminowners and maxCcbs are allowed as configurable. +The limits are added as attributes to the imm object +"opensafImm=opensafImm,safApp=safImmService". + +The default values configured for these attributes are : + +IMMSV_MAX_CLASSES 1000 +IMMSV_MAX_IMPLEMENTERS 3000 +IMMSV_MAX_ADMINOWNERS 2000 +IMMSV_MAX_CCBS 1 + +The user can not configure the values less than the default values. + +Notes on upgrading from OpenSAF 5.0 to OpenSAF 5.1 + +OpenSAF5.1 makes the IMM attributes as configurable (#195). +During a rolling upgrade from an earlier OpenSAF release to the 5.1 +release there will be nodes executing the older release concurrently +with nodes executing OpenSAF 5.0. Nodes executing the earlier release will not +recognize the new attributes introduced in imm config object from nodes executing 5.0. + +Because of this upgrade issue, the new attribute flag added in OpenSAF 5.1 is +not allowed unless a flag is toggled on in the opensafImmNostdFlags runtime +attribute in the object: + + opensafImm=opensafImm,safApp=safImmService. + +The following shell command must be used once all nodes are upgraded : + +immadm -o 1 -p opensafImmNostdFlags:SA_UINT32_T:256 \ + opensafImm=opensafImm,safApp=safImmService + +This will set bit 9 of the 'opensafImmNostdFlags' runtime attribute inside the immsv. +Operation-id '1' invoked on the object: + + 'opensafImm=opensafImm,safApp=safImmService' + + DEPENDENCIES -- 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
[devel] [PATCH 3 of 5] imm: Checking of Imm limits [#195]
osaf/services/saf/immsv/immnd/ImmModel.cc | 322 +- osaf/services/saf/immsv/immnd/ImmModel.hh |5 +- 2 files changed, 324 insertions(+), 3 deletions(-) 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 @@ -1154,6 +1154,13 @@ immModel_protocol50Allowed(IMMND_CB *cb) SA_TRUE : SA_FALSE; } +SaBoolT +immModel_protocol51Allowed(IMMND_CB *cb) +{ +return (ImmModel::instance(&cb->immModel)->protocol51Allowed()) ? +SA_TRUE : SA_FALSE; +} + OsafImmAccessControlModeT immModel_accessControlMode(IMMND_CB *cb) { @@ -3271,6 +3278,21 @@ ImmModel::classCreate(const ImmsvOmClass return SA_AIS_ERR_INVALID_PARAM; } +ObjectMap::iterator oit = sObjectMap.find(immObjectDn); +if(protocol51Allowed() && oit != sObjectMap.end() && !isLoading ){ +std::string immMaxClasses(OPENSAF_IMMSV_MAX_CLASSES); +ObjectInfo* immObject = oit->second; +ImmAttrValueMap::iterator avi = immObject->mAttrValueMap.find(immMaxClasses); +osafassert(avi != immObject->mAttrValueMap.end()); +osafassert(!(avi->second->isMultiValued())); +ImmAttrValue* valuep = avi->second; +unsigned int maxClasses = valuep->getValue_int(); +if( sClassMap.size() >= maxClasses){ +LOG_NO("ERR_NO_RESOURCES: maximum class limit %d has been reched for the cluster", + maxClasses); +return SA_AIS_ERR_NO_RESOURCES; +} +} ClassMap::iterator i = sClassMap.find(className); if (i == sClassMap.end()) { /* Class-name is unique case-sensitive. @@ -3597,6 +3619,8 @@ ImmModel::classCreate(const ImmsvOmClass } } + + if(illegal) { if(err == SA_AIS_OK) { LOG_NO("ERR_INVALID_PARAM: Problem with new class '%s'", className.c_str()); @@ -3966,6 +3990,34 @@ ImmModel::protocol50Allowed() return noStdFlags & OPENSAF_IMM_FLAG_PRT50_ALLOW; } + +bool +ImmModel::protocol51Allowed() +{ +//TRACE_ENTER(); +/* Assume that all nodes are running the same version when loading */ +if (sImmNodeState == IMM_NODE_LOADING) { +return true; +} +ObjectMap::iterator oi = sObjectMap.find(immObjectDn); +if(oi == sObjectMap.end()) { +TRACE_LEAVE(); +return false; +} + +ObjectInfo* immObject = oi->second; +ImmAttrValueMap::iterator avi = +immObject->mAttrValueMap.find(immAttrNostFlags); +osafassert(avi != immObject->mAttrValueMap.end()); +osafassert(!(avi->second->isMultiValued())); +ImmAttrValue* valuep = avi->second; +unsigned int noStdFlags = valuep->getValue_int(); + +//TRACE_LEAVE(); +return noStdFlags & OPENSAF_IMM_FLAG_PRT51_ALLOW; +} + + bool ImmModel::protocol41Allowed() { @@ -4114,6 +4166,44 @@ ImmModel::verifySchemaChange(const std:: verifyFailed = notCompatibleAtt(className, newClassInfo, attName, NULL, newAttr, NULL) || verifyFailed; newAttrs[inew->first] = newAttr; +if(!verifyFailed && (className == immClassName)){ +unsigned int val; +if ( attName == OPENSAF_IMMSV_MAX_CLASSES) { +val = newAttr->mDefaultValue.getValue_int(); +if( sClassMap.size() > val){ +LOG_NO("The Number of classes in the cluster %lu greater than the schema change" + "value %d", sClassMap.size(), val); +verifyFailed = true; + } +} + +if ( !verifyFailed && attName == OPENSAF_IMMSV_MAX_IMPLEMENTERS) { +val = newAttr->mDefaultValue.getValue_int(); +if( sImplementerVector.size() > val){ +LOG_NO("The Number of Implementers in the cluster %lu greater than the schema change" + "value %d", sImplementerVector.size(), val); +verifyFailed = true; +} +} + +if ( !verifyFailed && attName == OPENSAF_IMMSV_MAX_ADMINOWNERS) { +val = newAttr->mDefaultValue.getValue_int(); +if( sOwnerVector.size() > val){ +LOG_NO("The Number of AdminOwners in the cluster %lu greater than the schema change" + "value %d", sOwnerVector.size(), val); +verifyFailed = true; + } +} + +if ( !verifyFailed && attName == OPENSAF_IMMSV_MAX_CCBS) { +val = newAttr->mDefaultValue.getValue_int(); +if( sCcbVector.size() > val){ +LOG_NO("The Number of Ccbs in the cluster %lu greater than the schema change" +
[devel] [PATCH 4 of 5] imm: Added the updated OpensafImm class [#195]
tests/immsv/management/test_saImmOmAccessorGet_2.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/tests/immsv/management/test_saImmOmAccessorGet_2.c b/tests/immsv/management/test_saImmOmAccessorGet_2.c --- a/tests/immsv/management/test_saImmOmAccessorGet_2.c +++ b/tests/immsv/management/test_saImmOmAccessorGet_2.c @@ -133,7 +133,7 @@ void saImmOmAccessorGet_2_04(void) rc = saImmOmAccessorGet_2(accessorHandle, &objectName, accessorGetConfigAttrsToken, &attributes); /* Verify the number of config attributes */ cnt = print_SaImmAttrValuesT_2(attributes); -assert(cnt == 8); +assert(cnt == 12); test_validate(rc, SA_AIS_OK); safassert(saImmOmFinalize(immOmHandle), SA_AIS_OK); } -- 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
[devel] [PATCH 0 of 5] Review Request for imm:Hardcoded limits are made into config parameters [#195]
Summary: Hardcoded limits are added as config parameters [#195] Review request for Trac Ticket(s):195 Peer Reviewer(s): Zoran, Hung Affected branch(es): default Development branch: default Impacted area Impact y/n Docsn Build systemn RPM/packaging n Configuration files n Startup scripts n SAF servicesn OpenSAF servicesy Core libraries n Samples n Tests n Other n Comments (indicate scope for each "y" above): - changeset bd980ca7528061b3b8dac255d15b808871178526 Author: Neelakanta Reddy Date: Wed, 27 Jul 2016 13:48:35 +0530 imm: Remove the IMM limits checking in encoding and decoding [#195] changeset f389fb5fc59a506fb4342ccd44f333c3b6296e8b Author: Neelakanta Reddy Date: Wed, 27 Jul 2016 13:49:25 +0530 imm: Added new attributes to imm config class [#195] changeset 157b4ec00ae677a693985353f6916195b2cfbcba Author: Neelakanta Reddy Date: Wed, 27 Jul 2016 13:51:21 +0530 imm: Checking of Imm limits [#195] changeset e95dcbb8b133eab87d7fc98346a94b29f01a8245 Author: Neelakanta Reddy Date: Wed, 27 Jul 2016 13:53:20 +0530 imm: Added the updated OpensafImm class [#195] changeset 1059ddcaa88c7af100ab7f715894bda882802bd9 Author: Neelakanta Reddy Date: Wed, 27 Jul 2016 13:53:50 +0530 imm: updated README [#195] Complete diffstat: -- osaf/libs/common/immsv/immsv_evt.c | 69 --- osaf/libs/common/immsv/include/immsv_api.h |9 osaf/services/saf/immsv/README | 43 +++ osaf/services/saf/immsv/immloadd/imm_loader.cc | 28 +++- osaf/services/saf/immsv/immnd/ImmModel.cc | 322 ++- osaf/services/saf/immsv/immnd/ImmModel.hh |5 +- tests/immsv/management/test_saImmOmAccessorGet_2.c |2 +- 7 files changed, 412 insertions(+), 66 deletions(-) Testing Commands: - Test the maximum limits for each attribute. Modify the attributes to a new value and test Test while upgrading the node from 5.0 to default Testing, Expected Results: -- ERR_NO_RESOURCE or ERR_BAD_OPERATION is returned based on the verification against the results. Conditions of Submission: - Ack from reviewers Arch Built StartedLinux distro --- mipsn n mips64 n n x86 n n x86_64 y y powerpc n n powerpc64 n n Reviewer Checklist: --- [Submitters: make sure that your review doesn't trigger any checkmarks!] Your checkin has not passed review because (see checked entries): ___ Your RR template is generally incomplete; it has too many blank entries that need proper data filled in. ___ You have failed to nominate the proper persons for review and push. ___ Your patches do not have proper short+long header ___ You have grammar/spelling in your header that is unacceptable. ___ You have exceeded a sensible line length in your headers/comments/text. ___ You have failed to put in a proper Trac Ticket # into your commits. ___ You have incorrectly put/left internal data in your comments/files (i.e. internal bug tracking tool IDs, product names etc) ___ You have not given any evidence of testing beyond basic build tests. Demonstrate some level of runtime or other sanity testing. ___ You have ^M present in some of your files. These have to be removed. ___ You have needlessly changed whitespace or added whitespace crimes like trailing spaces, or spaces before tabs. ___ You have mixed real technical changes with whitespace and other cosmetic code cleanup changes. These have to be separate commits. ___ You need to refactor your submission into logical chunks; there is too much content into a single commit. ___ You have extraneous garbage in your review (merge commits etc) ___ You have giant attachments which should never have been sent; Instead you should place your content in a public tree to be pulled. ___ You have too many commits attached to an e-mail; resend as threaded commits, or place in a public tree for a pull. ___ You have resent this content multiple times without a clear indication of what has changed between each re-send. ___ You have failed to adequately and individually address all of the comments and change requests that were proposed in the initial review. ___ You have a misconfigured ~/.hgrc file (i.e. username, email etc) ___ Your computer have a badly configured date and time
[devel] [PATCH 1 of 5] imm: Remove the IMM limits checking in encoding and decoding [#195]
osaf/libs/common/immsv/immsv_evt.c | 69 +++-- osaf/libs/common/immsv/include/immsv_api.h | 9 +++ 2 files changed, 18 insertions(+), 60 deletions(-) diff --git a/osaf/libs/common/immsv/immsv_evt.c b/osaf/libs/common/immsv/immsv_evt.c --- a/osaf/libs/common/immsv/immsv_evt.c +++ b/osaf/libs/common/immsv/immsv_evt.c @@ -30,11 +30,6 @@ #include "osaf_extended_name.h" #include "saAis.h" -#define IMMSV_MAX_CLASSES 1000 -#define IMMSV_MAX_IMPLEMENTERS 3000 -#define IMMSV_MAX_ADMINOWNERS 2000 -#define IMMSV_MAX_CCBS 1 - #define IMMSV_RSRV_SPACE_ASSERT(P,B,S) P=ncs_enc_reserve_space(B,S);osafassert(P) #define IMMSV_FLTN_SPACE_ASSERT(P,M,B,S) P=ncs_dec_flatten_space(B,M,S);osafassert(P) @@ -820,7 +815,6 @@ static void immsv_evt_enc_class(NCS_UBAI static uint32_t immsv_evt_dec_class(NCS_UBAID *i_ub, IMMSV_CLASS_LIST **r) { - int depth = 1; uint8_t c8; do { @@ -850,13 +844,7 @@ static uint32_t immsv_evt_dec_class(NCS_ ncs_dec_skip_space(i_ub, 1); r = &((*r)->next); - ++depth; - } while (c8 && (depth < IMMSV_MAX_CLASSES)); - - if (depth >= IMMSV_MAX_CLASSES) { - LOG_ER("TOO MANY classes line: %u", __LINE__); - return NCSCC_RC_OUT_OF_MEM; - } + } while (c8); return NCSCC_RC_SUCCESS; } @@ -918,7 +906,6 @@ static void immsv_evt_enc_impl(NCS_UBAID static uint32_t immsv_evt_dec_impl(NCS_UBAID *i_ub, IMMSV_IMPL_LIST **q) { - int depth = 1; uint8_t c8; do { @@ -950,13 +937,7 @@ static uint32_t immsv_evt_dec_impl(NCS_U ncs_dec_skip_space(i_ub, 1); q = &((*q)->next); - ++depth; - } while (c8 && (depth < IMMSV_MAX_IMPLEMENTERS)); - - if (depth >= IMMSV_MAX_IMPLEMENTERS) { - LOG_ER("TOO MANY implementers line:%u", __LINE__); - return NCSCC_RC_OUT_OF_MEM; - } + } while (c8); return NCSCC_RC_SUCCESS; } @@ -1015,7 +996,6 @@ static uint32_t immsv_evt_enc_admo(NCS_U static uint32_t immsv_evt_dec_admo(NCS_UBAID *i_ub, IMMSV_ADMO_LIST **p) { - int depth = 1; uint8_t c8; do { @@ -1052,13 +1032,7 @@ static uint32_t immsv_evt_dec_admo(NCS_U ncs_dec_skip_space(i_ub, 1); p = &((*p)->next); - ++depth; - } while (c8 && (depth < IMMSV_MAX_ADMINOWNERS)); - - if (depth >= IMMSV_MAX_ADMINOWNERS) { - LOG_ER("TOO MANY Admin Owners"); - return NCSCC_RC_OUT_OF_MEM; - } + } while (c8 ); return NCSCC_RC_SUCCESS; } @@ -1791,61 +1765,38 @@ static uint32_t immsv_evt_enc_sublevels( return immsv_evt_enc_name_list(o_ub, i_evt->info.immnd.info.admReq.objectNames); } else if ((i_evt->info.immnd.type == IMMND_EVT_ND2ND_SYNC_FINALIZE) || (i_evt->info.immnd.type == IMMND_EVT_ND2ND_SYNC_FINALIZE_2)) { - int depth = 0; uint8_t *p8; IMMSV_ADMO_LIST *p = i_evt->info.immnd.info.finSync.adminOwners; - while (p && (depth < IMMSV_MAX_ADMINOWNERS)) { + while (p ) { if (immsv_evt_enc_admo(o_ub, p) != NCSCC_RC_SUCCESS) { return NCSCC_RC_OUT_OF_MEM; } p = p->next; - ++depth; } - if (depth >= IMMSV_MAX_ADMINOWNERS) { - LOG_ER("TOO MANY admin owners line:%u", __LINE__); - return NCSCC_RC_OUT_OF_MEM; - } - - depth = 0; IMMSV_IMPL_LIST *q = i_evt->info.immnd.info.finSync.implementers; - while (q && (depth < IMMSV_MAX_IMPLEMENTERS)) { + while (q ) { immsv_evt_enc_impl(o_ub, q); q = q->next; - ++depth; } - if (depth >= IMMSV_MAX_IMPLEMENTERS) { - LOG_ER("TOO MANY implementers line:%u", __LINE__); - return NCSCC_RC_OUT_OF_MEM; - } - - depth = 0; IMMSV_CLASS_LIST *r = i_evt->info.immnd.info.finSync.classes; - while (r && (depth < IMMSV_MAX_CLASSES)) { + while (r ) { immsv_evt_enc_class(o_ub, r); r = r->next; - ++depth; - } - - if (depth >= IMMSV_MAX_CLASSES) { - LOG_ER("TOO MANY cla
[devel] [PATCH 2 of 5] imm: Added new attributes to imm config class [#195]
osaf/services/saf/immsv/immloadd/imm_loader.cc | 28 - 1 files changed, 26 insertions(+), 2 deletions(-) diff --git a/osaf/services/saf/immsv/immloadd/imm_loader.cc b/osaf/services/saf/immsv/immloadd/imm_loader.cc --- a/osaf/services/saf/immsv/immloadd/imm_loader.cc +++ b/osaf/services/saf/immsv/immloadd/imm_loader.cc @@ -293,12 +293,16 @@ void opensafClassCreate(SaImmHandleT imm { SaAisErrorT err = SA_AIS_OK; int retries=0; -SaImmAttrDefinitionT_2 d1, d2, d3, d4, d5, d6, d7, d8, d9; +SaImmAttrDefinitionT_2 d1, d2, d3, d4, d5, d6, d7, d8, d9, d10, d11, d12, d13; SaUint32T nost_flags_default = 0; SaUint32T batch_size_default = IMMSV_DEFAULT_MAX_SYNC_BATCH_SIZE; SaUint32T extended_names_enabled_default = 0; SaUint32T access_control_mode_default = IMM_ACCESS_CONTROL_MODE; SaUint32T absent_scs_allowed_default = 0; +SaUint32T max_classes_default = 1000; +SaUint32T max_implementers_default = 3000; +SaUint32T max_adminOwners_default = 2000; +SaUint32T max_ccbs_default = 1; d1.attrName = (char *) OPENSAF_IMM_ATTR_RDN; d1.attrValueType = SA_IMM_ATTR_SANAMET; @@ -346,8 +350,28 @@ void opensafClassCreate(SaImmHandleT imm d9.attrFlags = SA_IMM_ATTR_RUNTIME | SA_IMM_ATTR_CACHED | SA_IMM_ATTR_PERSISTENT; d9.attrDefaultValue = &absent_scs_allowed_default; +d10.attrName = (char *) OPENSAF_IMMSV_MAX_CLASSES; +d10.attrValueType = SA_IMM_ATTR_SAUINT32T; +d10.attrFlags = SA_IMM_ATTR_CONFIG | SA_IMM_ATTR_WRITABLE; +d10.attrDefaultValue = &max_classes_default; + +d11.attrName = (char *) OPENSAF_IMMSV_MAX_IMPLEMENTERS; +d11.attrValueType = SA_IMM_ATTR_SAUINT32T; +d11.attrFlags = SA_IMM_ATTR_CONFIG | SA_IMM_ATTR_WRITABLE; +d11.attrDefaultValue = &max_implementers_default; + +d12.attrName = (char *) OPENSAF_IMMSV_MAX_ADMINOWNERS; +d12.attrValueType = SA_IMM_ATTR_SAUINT32T; +d12.attrFlags = SA_IMM_ATTR_CONFIG | SA_IMM_ATTR_WRITABLE; +d12.attrDefaultValue = &max_adminOwners_default; + +d13.attrName = (char *) OPENSAF_IMMSV_MAX_CCBS; +d13.attrValueType = SA_IMM_ATTR_SAUINT32T; +d13.attrFlags = SA_IMM_ATTR_CONFIG | SA_IMM_ATTR_WRITABLE; +d13.attrDefaultValue = &max_ccbs_default; + const SaImmAttrDefinitionT_2* attrDefs[] = - {&d1, &d2, &d3, &d4, &d5, &d6, &d7, &d8, &d9, 0}; + {&d1, &d2, &d3, &d4, &d5, &d6, &d7, &d8, &d9, &d10, &d11, &d12, &d13, 0}; do {/* Create the class */ -- 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
[devel] [PATCH 0 of 1] Review Request for AMFD: Initialize CLM, NTF handle in thread [#1828] V2
Summary: AMFD: Initialize CLM, NTF handle in thread [#1828] V2 Review request for Trac Ticket(s): 1828 Peer Reviewer(s): AMF maintainers Pull request to: Gary Affected branch(es): 5.0, default Development branch: default Impacted area Impact y/n Docsn Build systemn RPM/packaging n Configuration files n Startup scripts n SAF servicesy OpenSAF servicesn Core libraries n Samples n Tests n Other n Comments (indicate scope for each "y" above): - In this V2, amfd does CLM/NTF init when amfd get active/standby role changeset 5ae93844c6a37b4546468635a92d3c70d85aec82 Author: Minh Hon Chau Date: Wed, 27 Jul 2016 18:00:25 +1000 AMFD: Initialize CLM, NTF handle in thread [#1828] V2 In new controller reallocation scenario with roaming sc feature, if immnd dies in the node becoming active, the circular dependencies among Opensaf services appear, which leads eventually to a reboot. The dependencies are: .clmd can not use IMM services since immnd dies .immnd needs restarted by amfnd .amfnd is hanging since amfnd is calling CLM services .amfd is also hanging since amfd is calling CLM and NTF services .ntfd is hanging due to logd's dependencies on IMM The problem could be solved if: . amfd initializes NTF, CLM handle in thread in initialization phase . amfnd initializes CLM in thread if amfnd receives clm bad handle Since amfnd has already initialized CLM in thread up on receiving clm bad handle. This patch does initialze CLM, NTF in thread at amfd side. Also, threading initialization in this patch can be refactored later by utilizing the support of #1609 Complete diffstat: -- osaf/services/saf/amf/amfd/clm.cc| 103 --- osaf/services/saf/amf/amfd/include/cb.h |7 ++- osaf/services/saf/amf/amfd/include/clm.h |6 ++- osaf/services/saf/amf/amfd/include/ntf.h |3 + osaf/services/saf/amf/amfd/main.cc | 17 +++- osaf/services/saf/amf/amfd/ntf.cc| 85 ++ osaf/services/saf/amf/amfd/role.cc | 24 ++- 7 files changed, 205 insertions(+), 40 deletions(-) Testing Commands: - <> Testing, Expected Results: -- <> Conditions of Submission: - ack from reviewers Arch Built StartedLinux distro --- mipsn n mips64 n n x86 n n x86_64 y y powerpc n n powerpc64 n n Reviewer Checklist: --- [Submitters: make sure that your review doesn't trigger any checkmarks!] Your checkin has not passed review because (see checked entries): ___ Your RR template is generally incomplete; it has too many blank entries that need proper data filled in. ___ You have failed to nominate the proper persons for review and push. ___ Your patches do not have proper short+long header ___ You have grammar/spelling in your header that is unacceptable. ___ You have exceeded a sensible line length in your headers/comments/text. ___ You have failed to put in a proper Trac Ticket # into your commits. ___ You have incorrectly put/left internal data in your comments/files (i.e. internal bug tracking tool IDs, product names etc) ___ You have not given any evidence of testing beyond basic build tests. Demonstrate some level of runtime or other sanity testing. ___ You have ^M present in some of your files. These have to be removed. ___ You have needlessly changed whitespace or added whitespace crimes like trailing spaces, or spaces before tabs. ___ You have mixed real technical changes with whitespace and other cosmetic code cleanup changes. These have to be separate commits. ___ You need to refactor your submission into logical chunks; there is too much content into a single commit. ___ You have extraneous garbage in your review (merge commits etc) ___ You have giant attachments which should never have been sent; Instead you should place your content in a public tree to be pulled. ___ You have too many commits attached to an e-mail; resend as threaded commits, or place in a public tree for a pull. ___ You have resent this content multiple times without a clear indication of what has changed between each re-send. ___ You have failed to adequately and individually address all of the comments and change requests that were proposed in the initial review. ___ You have a misconfigured ~/.hgrc file (i.e. username, email etc) ___ Your computer ha
[devel] [PATCH 1 of 1] AMFD: Initialize CLM, NTF handle in thread [#1828] V2
osaf/services/saf/amf/amfd/clm.cc| 103 ++ osaf/services/saf/amf/amfd/include/cb.h |7 +- osaf/services/saf/amf/amfd/include/clm.h |6 +- osaf/services/saf/amf/amfd/include/ntf.h |3 + osaf/services/saf/amf/amfd/main.cc | 17 +--- osaf/services/saf/amf/amfd/ntf.cc| 85 + osaf/services/saf/amf/amfd/role.cc | 24 +++--- 7 files changed, 205 insertions(+), 40 deletions(-) In new controller reallocation scenario with roaming sc feature, if immnd dies in the node becoming active, the circular dependencies among Opensaf services appear, which leads eventually to a reboot. The dependencies are: .clmd can not use IMM services since immnd dies .immnd needs restarted by amfnd .amfnd is hanging since amfnd is calling CLM services .amfd is also hanging since amfd is calling CLM and NTF services .ntfd is hanging due to logd's dependencies on IMM The problem could be solved if: . amfd initializes NTF, CLM handle in thread in initialization phase . amfnd initializes CLM in thread if amfnd receives clm bad handle Since amfnd has already initialized CLM in thread up on receiving clm bad handle. This patch does initialze CLM, NTF in thread at amfd side. Also, threading initialization in this patch can be refactored later by utilizing the support of #1609 diff --git a/osaf/services/saf/amf/amfd/clm.cc b/osaf/services/saf/amf/amfd/clm.cc --- a/osaf/services/saf/amf/amfd/clm.cc +++ b/osaf/services/saf/amf/amfd/clm.cc @@ -386,14 +386,26 @@ static const SaClmCallbacksT_4 clm_callb /*.saClmClusterTrackCallback =*/ clm_track_cb }; -SaAisErrorT avd_clm_init(void) +SaAisErrorT avd_clm_init(AVD_CL_CB* cb) { -SaAisErrorT error = SA_AIS_OK; + SaAisErrorT error = SA_AIS_OK; + SaClmHandleT clm_handle = 0; + SaSelectionObjectT sel_obj = 0; + cb->clmHandle = 0; + cb->clm_sel_obj = 0; TRACE_ENTER(); + /* +* TODO: This CLM initialization thread can be re-factored +* after having osaf dedicated thread, so that all APIs calls +* to external service can be automatically retried with result +* code (TRY_AGAIN, TIMEOUT, UNAVAILABLE), or reinitialized within +* BAD_HANDLE. Also, duplicated codes in initialization thread +* will be moved to osaf dedicated thread +*/ for (;;) { SaVersionT Version = { 'B', 4, 1 }; - error = saClmInitialize_4(&avd_cb->clmHandle, &clm_callbacks, &Version); + error = saClmInitialize_4(&clm_handle, &clm_callbacks, &Version); if (error == SA_AIS_ERR_TRY_AGAIN || error == SA_AIS_ERR_TIMEOUT || error == SA_AIS_ERR_UNAVAILABLE) { @@ -404,15 +416,21 @@ SaAisErrorT avd_clm_init(void) osaf_nanosleep(&kHundredMilliseconds); continue; } - if (error == SA_AIS_OK) break; - LOG_ER("Failed to Initialize with CLM: %u", error); + if (error == SA_AIS_OK) { + break; + }else { + LOG_ER("Failed to Initialize with CLM: %u", error); + goto done; + } + } + cb->clmHandle = clm_handle; + error = saClmSelectionObjectGet(cb->clmHandle, &sel_obj); + if (error != SA_AIS_OK) { + LOG_ER("Failed to get selection object from CLM %u", error); + cb->clmHandle = 0; goto done; } - error = saClmSelectionObjectGet(avd_cb->clmHandle, &avd_cb->clm_sel_obj); - if (SA_AIS_OK != error) { - LOG_ER("Failed to get selection object from CLM %u", error); - goto done; - } + cb->clm_sel_obj = sel_obj; TRACE("Successfully initialized CLM"); @@ -428,10 +446,15 @@ SaAisErrorT avd_clm_track_start(void) TRACE_ENTER(); error = saClmClusterTrack_4(avd_cb->clmHandle, trackFlags, nullptr); -if (SA_AIS_OK != error) -LOG_ER("Failed to start cluster tracking %u", error); - -TRACE_LEAVE(); + if (error != SA_AIS_OK) { + if (error == SA_AIS_ERR_TRY_AGAIN || error == SA_AIS_ERR_TIMEOUT || + error == SA_AIS_ERR_UNAVAILABLE) { + LOG_WA("Failed to start cluster tracking %u", error); + } else { + LOG_ER("Failed to start cluster tracking %u", error); + } + } + TRACE_LEAVE(); return error; } @@ -468,3 +491,55 @@ void clm_node_terminate(AVD_AVND *node) else TRACE("Waiting for the pending SU presence state updates"); } + +static void* avd_clm_init_thread(void* arg) +{ + TRACE_ENTER(); + AVD_CL_CB* cb = static_cast(arg); + SaAisErrorT error = SA_AIS_OK; + + if (avd_clm_init(cb) != SA_