I meant:
* the TIPC_PUBLISHED event and TIPC_WITHDRAWN event are from Dsock
* the MDS messages are from BSRsock
* and the auth-server in running in a separate thread (handling
MDS_REGISTER_REQ/MDS_UNREGISTER_REQ messages)
So we can't control the order of up/down events and the messages that will be
received on IMM server.
In IMM library/agent, here's what we do when finializing-initializing handles:
1. Send IMMND_EVT_A2ND_IMM_FINALIZE
1. mds_auth_server_disconnect()
1. Uninstall MDS (NCSMDS_TYPE == MDS_UNINSTALL)
1. Install MDS (NCSMDS_TYPE == MDS_INSTALL)
1. mds_auth_server_connect()
1. Send IMMND_EVT_A2ND_IMM_INIT
So normally, on IMM server, the events/messages will be received in the
following order:
1. Receive IMMND_EVT_A2ND_IMM_FINALIZE
1. **MDS_UNREGISTER_REQ messages**
1. **NCSMDS_DOWN event (TIPC_WITHDRAWN)**
1. **NCSMDS_UP event (TIPC_PUBLISHED)**
1. **MDS_REGISTER_REQ messages**
1. Receive IMMND_EVT_A2ND_IMM_INIT
When receiving MDS_UNREGISTER_REQ messages, the process info is removed from
process_info_db. Then when the TIPC_WITHDRAWN event comes, mds_mcm_svc_down()
will check and see that process info is already cleared, timer is not started.
But sometimes we receive in order like this:
1. Receive IMMND_EVT_A2ND_IMM_FINALIZE
1. **MDS_REGISTER_REQ messages**
1. **MDS_UNREGISTER_REQ messages**
1. Receive IMMND_EVT_A2ND_IMM_INIT
1. **NCSMDS_DOWN event (TIPC_WITHDRAWN)**
1. **NCSMDS_UP event (TIPC_PUBLISHED)**
When receiving MDS_UNREGISTER_REQ messages, the process info is removed from
process_info_db. Then MDS_REGISTER_REQ comes right after that and the process
info is added to process_info_db. Then when the TIPC_WITHDRAWN event comes,
mds_mcm_svc_down() will check and see that process info is still there, timer
is started. After 10 seconds, the process info is cleared.
I think the process info should not be cleared in this case (by clearing the
timer when receving TIPC_PUBLISHED event).
---
** [tickets:#1825] MDS: When saImmOmInitialize was invoked, MDS sent ‘pid = 0’
in MDS_CALLBACK_RECEIVE_INFO.**
**Status:** unassigned
**Milestone:** 4.7.2
**Created:** Fri May 13, 2016 12:34 PM UTC by Rafael
**Last Updated:** Mon May 23, 2016 03:58 AM UTC
**Owner:** nobody
**Attachments:**
-
[sc2_mds.log](https://sourceforge.net/p/opensaf/tickets/1825/attachment/sc2_mds.log)
(2.6 MB; text/x-log)
This happens only some of the time.
First this is called from an application:
saImmOmInitialize(immHandle, NULL, &version)
Then the system log shows this error:
May 13 02:31:53 sc2 osafimmnd[6042]: WA immnd_evt_proc_imm_init: PID 0
(7150) for 2020fb1d13cb8, MDS problem?
May 13 02:31:53 sc2 osafimmnd[6042]: WA immnd_evt_proc_imm_init: PID 0
(7150) for 2020fb1d13cb8, MDS problem?
May 13 02:31:55 sc2 osafimmnd[6042]: NO Ccb 176 COMMITTED (LDE)
May 13 02:31:55 sc2 osafimmnd[6042]: WA immnd_evt_proc_imm_init: PID 0
(7150) for 2020fb1d13cb8, MDS problem?
May 13 02:31:55 sc2 osafimmnd[6042]: WA immnd_evt_proc_imm_init: PID 0
(7150) for 2020fb1d13cb8, MDS problem?
---
Sent from sourceforge.net because [email protected] 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.------------------------------------------------------------------------------
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
_______________________________________________
Opensaf-tickets mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
