- **Milestone**: 5.0.1 --> 5.0.2
---
** [tickets:#1885] CLM : LIbrary gives false success for couple of APIs , once
controller joins back from headless**
**Status:** unassigned
**Milestone:** 5.0.2
**Created:** Mon Jun 20, 2016 09:17 AM UTC by Srikanth R
**Last Updated:** Mon Jun 20, 2016 09:18 AM UTC
**Owner:** nobody
Setup :
5 nodes setup with 3 controllers.
Version : opensaf 5.0 GA
Steps performed :
-> Invoke saClmInitialize_4
-> Create a thread by calling saClmDispatch with DISPATCH_BLOCKING as argument.
-> Invoke saClmClusterNodeGet_4
-> Create headless state.
-> Invoke saClmClusterTrack_4 with TRACK_CURRENT and TRACK_START_STEP
-> Invoke saClmClusterNodeGet_4
Observed behavior :
The first three apis successfully returned SA_AIS_OK.
Once the headless scenario is induced, saClmClusterTrack_4 api returned
TRY_AGAIN until one of the controller joined as active controller. Here the api
returned SA_AIS_OK, but no callback with CURRENT nodes info is delivered.
The thread in which Dispatch is called, returned with SA_AIS_OK.
Even though internally, the handle is marked as BAD_HANDLE. The subsequent
calls to saClmClusterTrack and saClmClusterNodeGet_4 returned successfully.
Aug 2 19:36:22.990719 clma [10058:clma_api.c:1035] TR RC before give handle
flagsTrack 6
Aug 2 19:36:22.990730 clma [10058:clma_api.c:1038] << clmaclustertrack
Aug 2 19:36:22.990740 clma [10058:clma_api.c:0938] << saClmClusterTrack_4
Aug 2 19:36:26.998572 clma [10058:clma_api.c:0934] >> saClmClusterTrack_4
Aug 2 19:36:26.998625 clma [10058:clma_api.c:0968] >> clmaclustertrack
Aug 2 19:36:26.998636 clma [10058:clma_api.c:0986] TR CLMS down
Aug 2 19:36:26.998642 clma [10058:clma_api.c:1035] TR RC before give handle
flagsTrack 6
Aug 2 19:36:26.998648 clma [10058:clma_api.c:1038] << clmaclustertrack
Aug 2 19:36:26.998657 clma [10058:clma_api.c:0938] << saClmClusterTrack_4
Aug 2 19:36:30.837965 clma [10058:clma_mds.c:0947] T2 CLMA Rcvd MDS subscribe
evt from svc 34
Aug 2 19:36:30.837983 clma [10058:clma_mds.c:0978] T2 MSG from CLMS
NCSMDS_NEW_ACTIVE/UP
Aug 2 19:36:30.837989 clma [10058:clma_mds.c:0989] TR ** Marking handle as
BAD**
Aug 2 19:36:30.839058 clma [10058:sysf_ipc.c:0363] TR IN LEAP_DBG_SINK
Aug 2 19:36:30.839070 clma [10058:clma_util.c:0625] << clma_hdl_cbk_dispatch
Aug 2 19:36:30.839076 clma [10058:clma_api.c:0793] << saClmDispatch
Aug 2 19:36:31.259065 clma [10058:clma_api.c:0934] >> saClmClusterTrack_4
Aug 2 19:36:31.259088 clma [10058:clma_api.c:0968] >> clmaclustertrack
Aug 2 19:36:31.259097 clma [10058:clma_util.c:0036] >> clma_validate_version
Aug 2 19:36:31.259103 clma [10058:clma_util.c:0042] << clma_validate_version
Aug 2 19:36:31.259108 clma [10058:clma_api.c:1009] TR B.4.1 version
Aug 2 19:36:31.259113 clma [10058:clma_api.c:0140] >>
clma_validate_flags_buf_4: flags=0x15
Aug 2 19:36:31.259118 clma [10058:clma_api.c:0176] << clma_validate_flags_buf_4
Aug 2 19:36:31.259124 clma [10058:clma_api.c:1020] TR RC after validate
flagsTrack 1
Aug 2 19:36:31.259129 clma [10058:clma_util.c:0036] >> clma_validate_version
Aug 2 19:36:31.259140 clma [10058:clma_util.c:0042] << clma_validate_version
Aug 2 19:36:31.259145 clma [10058:clma_mds.c:1274] >> clma_mds_msg_async_send
Aug 2 19:36:31.259158 clma [10058:clma_mds.c:0317] >> clma_mds_enc
Aug 2 19:36:31.259166 clma [10058:clma_mds.c:0352] T2 msgtype: 0
Aug 2 19:36:31.259171 clma [10058:clma_mds.c:0366] T2 api_info.type: 2
Aug 2 19:36:31.259177 clma [10058:clma_mds.c:0118] >> clma_enc_track_start_msg
Aug 2 19:36:31.259182 clma [10058:clma_mds.c:0134] << clma_enc_track_start_msg
Aug 2 19:36:31.259187 clma [10058:clma_mds.c:0407] << clma_mds_enc
Aug 2 19:36:31.259260 clma [10058:clma_mds.c:1296] << clma_mds_msg_async_send
Aug 2 19:36:31.259272 clma [10058:clma_api.c:0455] << clma_send_md
If Dispatch api is called once AGAIN after the controller joins , BAD_HANDLE
is returned.
Expected behavior :
If the handle is marked as BAD internally, the apis saClmClusterTrack_4 and
saClmClusterNodeGet_4 should also return BAD_HANDLE once the controller joins
back. Currently Dispatch returns BAD_HANDLE
---
Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is
subscribed to https://sourceforge.net/p/opensaf/tickets/
To unsubscribe from further messages, a project admin can change settings at
https://sourceforge.net/p/opensaf/admin/tickets/options. Or, if this is a
mailing list, you can unsubscribe from the mailing list.
------------------------------------------------------------------------------
_______________________________________________
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
