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 .

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

Reply via email to