Sorry, it is load_pid that controls this but it shopuld be (-1) which means
unassigned.
/AndersBj
________________________________
From: Anders Björnerstedt
Sent: den 20 augusti 2014 13:40
To: '[opensaf:tickets] '
Subject: RE: [opensaf:tickets] #995 IMM: after immnd restart amfd fails to
become class implementer
It should be sync_pid.
/AndersBj
________________________________
From: Hans Feldt [mailto:[email protected]]
Sent: den 20 augusti 2014 13:11
To: [opensaf:tickets]
Subject: [opensaf:tickets] #995 IMM: after immnd restart amfd fails to become
class implementer
I think I have found the issue, Initialize is supposed to return TRYAGAIN as
long as load/sync is in progress. This depends on a proper PID stored in
"load_pid". However this value is empty after immnd restart since the resurrect
logic in IMMA does not work as before. Since Initialize succeeds the client
will continue with for example ClassImplementerSet which will return TIMEOUT.
That since that message is discarded by the immnd server.
Investigating changes, probably in MDS usage of the connect function
________________________________
[tickets:#995]<http://sourceforge.net/p/opensaf/tickets/995> IMM: after immnd
restart amfd fails to become class implementer
Status: assigned
Milestone: 4.5.0
Created: Tue Aug 19, 2014 10:36 AM UTC by Hans Feldt
Last Updated: Wed Aug 20, 2014 09:26 AM UTC
Owner: Hans Feldt
Seems like the IMM access control changes triggers some new behavior around the
IMM "resurrect" logic that cause client failure after immnd restart.
Test case is simply to kill immnd on a controller. In most cases it ends up
with node reboot since amfd cannot become class implementer. Timeout is
returned which is not handled properly.
If this cannot be resolved rather quickly I am afraid the IMM access control
feature should be backed out.
________________________________
Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/opensaf/tickets/995/<https://sourceforge.net/p/opensaf/tickets/995>
To unsubscribe from further messages, please visit
https://sourceforge.net/auth/subscriptions/<https://sourceforge.net/auth/subscriptions>
---
** [tickets:#995] IMM: after immnd restart amfd fails to become class
implementer**
**Status:** assigned
**Milestone:** 4.5.0
**Created:** Tue Aug 19, 2014 10:36 AM UTC by Hans Feldt
**Last Updated:** Wed Aug 20, 2014 11:11 AM UTC
**Owner:** Hans Feldt
Seems like the IMM access control changes triggers some new behavior around the
IMM "resurrect" logic that cause client failure after immnd restart.
Test case is simply to kill immnd on a controller. In most cases it ends up
with node reboot since amfd cannot become class implementer. Timeout is
returned which is not handled properly.
If this cannot be resolved rather quickly I am afraid the IMM access control
feature should be backed out.
---
Sent from sourceforge.net because [email protected] is
subscribed to http://sourceforge.net/p/opensaf/tickets/
To unsubscribe from further messages, a project admin can change settings at
http://sourceforge.net/p/opensaf/admin/tickets/options. Or, if this is a
mailing list, you can unsubscribe from the mailing list.
------------------------------------------------------------------------------
Slashdot TV.
Video for Nerds. Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
Opensaf-tickets mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
