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

Reply via email to