On 27-Jun-14 9:49 PM, Mark Garstin wrote: > Hans, > > You are correct, I'm only restarting the Proxy component (albeit by the > sledgehammer approach of a kill -9 on the process), not the entire node. > > When the Proxy comes back up it receives its own CSI set but not a > "refresher" CSI set for the Proxied component. > > IMHO, I would think that the way to get all of the CSI's for a Proxied > component that is still alive would be when the saAmfComponentRegister API is > called by the Proxy to register the Proxied component. Proxy is re-registering proxied as soon as proxy is restarted. Thus there is no fault reported on proxied and it works seamlessly. But the interface between proxy and proxied is based on user choice. When proxy restarted and re-registers proxied successfully, it will have to surely reinitialize its interface with the proxied. As part of this, prioxy can ask even proxied for which CSI proxied has assignment.
Thanks, Praveen > Either some sort of flag could be included in the register call that > requests a refresh of the Proxied component's CSI's or, perhaps, AMF can be > smart about it and realize that since this is a reassignment of the proxied > component to a new proxy then it would automatically send all of the CSI's in > a CSI set callback to the Proxy. > > If this were to be done then perhaps an extra element should probably be > added to the SaAmfCSITransitionDescriptorT enum called "SA_AMF_CSI_REFRESH = > 5". > > Barring the automatic approach it could be done on demand using a new API, > something like: > > SaAisErrorT saAmfCSIGet( > SaAmfHandleT amfHandle, > const SaNameT *compName > ); > > This would then trigger either an SaAmfCSISetCallbackT (with or without the > new flag indicating refresh) or a completely new callback that would be > interpreted only as a refresh of the CSI's assigned to the Proxied component. > > Cheers, > > > > Nark Garstin > > -----Original Message----- > From: Hans Feldt > Sent: June-27-14 3:54 AM > To: praveen malviya; Mark Garstin > Cc: [email protected] > Subject: RE: [users] Proxy looses CSI name for Proxied component after Proxy > is rebooted > > Inline > /Hans > >> -----Original Message----- >> From: praveen malviya [mailto:[email protected]] >> Sent: den 27 juni 2014 12:02 >> To: Mark Garstin >> Cc: [email protected] >> Subject: Re: [users] Proxy looses CSI name for Proxied component after >> Proxy is rebooted >> >> >> On 26-Jun-14 11:17 PM, Mark Garstin wrote: >>> OpenSAF Team, >>> >>> I've been running some integration tests on a Proxy/Proxied >>> component pair (under OpenSAF 4.3) whereby the Proxy component >> is killed (-9) abruptly (this is to test the recovery mechanism of >> OpenSAF for the Proxy and the Proxy's ability to reconnect to an already >> running Proxied component without interruption of the services in the >> Proxied component). >>> This all runs fine with OpenSAF rebooting the Proxy and the Proxy >>> reconnecting to the Proxied component without missing a step. >> The problem that arises, however, is that the Proxy loses the CSI name for >> the Proxied component. >>> >>> * During regular start up OpenSAF automatically sends a CSI set >>> callback request to the Proxy for the Proxied component with >> the flags field set to ADD. >>> * The Proxy sees this flag and then copies the CSI name in it to a >>> local variable before sending a message to the Proxied >> component telling it which state it needs to go to. >>> * The Proxy then calls saAmfProtectionGroupTrack_4 and passes it >>> the CSI name for the Proxied component. >>> >>> * This starts Group Track messages going to the Proxied component >>> (our setup requires that the 2N redundant Proxied >> components know the readiness state of their redundant partners). >>> Again, this all works fine and dandy, until the Proxy is killed and >>> rebooted. >>> >>> As already stated, the Proxy is rebooted and re-establishes >>> communications with the Proxied component (the Proxy, therefore, re- >> registers the Proxied component as a proxied component). >> During reboot, AMF will move assignments from both proxy and proxied >> components to their standby counter parts on different node. >> After node joins and when proxy registers proxied again, proxy should >> get standby/active assignments for the proxied component based on red >> model of their SG . > [Hans] I assume Mark does not mean system reboot just proxy restart. In that > case it will I guess get a CSI set standby for the proxy CSI and that is it. > No CSI set for the proxied. If this is an important use case that cannot be > solved in another way I guess it could be added to the list of enhancements. > Not sure how the interface can look though... > >> Thanks, >> Praveen >>> The problem is that since the Proxy has been rebooted it no longer >>> has the CSI name for the Proxied component and, therefore, >> can't call saAmfProtectionGroupTrack_4. If I run activities on the >> other Proxied component that would trigger a >> saAmfProtectionGroupTrackCallback_4 I only see those callbacks on the >> other Proxy. The Proxy that was rebooted does not see any of them. The >> Proxied component of the rebooted Proxy ends up retaining stale information >> about the other Proxied component. >>> The Proxied component does continue to receive CSI set messages (and >>> the Proxy can acquire the CSI name from those callbacks, >> even though the ADD flag is not set) but if there were any changes in >> the state of the other Proxied component before a CSI set callback comes in >> then that information is not received. >>> Is there some method I can use in the rebooted Proxy to get the CSI name of >>> its Proxied component on demand? >>> >>> Cheers, >>> >>> >>> >>> Mark Garstin >>> Ericsson >>> -------------------------------------------------------------------- >>> ---------- Open source business process management suite built on >>> Java and Eclipse Turn processes into business applications with >>> Bonita BPM Community Edition Quickly connect people, data, and >>> systems into organized workflows Winner of BOSSIE, CODIE, OW2 and >>> Gartner awards http://p.sf.net/sfu/Bonitasoft >>> _______________________________________________ >>> Opensaf-users mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/opensaf-users >> >> ---------------------------------------------------------------------- >> -------- Open source business process management suite built on Java >> and Eclipse Turn processes into business applications with Bonita BPM >> Community Edition Quickly connect people, data, and systems into >> organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards >> http://p.sf.net/sfu/Bonitasoft >> _______________________________________________ >> Opensaf-users mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/opensaf-users ------------------------------------------------------------------------------ Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft _______________________________________________ Opensaf-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensaf-users
