This issue is reproducible on the changeset: 4565:e8ae1895d8e3.
However there is slight change in the steps to reproduce it.
Si-swap operation should be issued two times on two different SIs.
In the first si-swap on a SI2 one of the components should return
FAILED_OPERATION.
Second si-swap should be issued on any SI other than SI2.
InvocationId related to both si-swap operations:
[root@CON-PC amf_demo]# grep admin_operation_cb /var/log/opensaf/osafamfd
Oct 29 17:17:33.593633 osafamfd [11367:imm.cc:0485] >> admin_operation_cb:
'safSi=AmfDemo,safApp=AmfDemo1', invocation: 55834574849, op: 7
Oct 29 17:17:33.616872 osafamfd [11367:imm.cc:0495] << admin_operation_cb
Oct 29 17:18:39.152081 osafamfd [11367:imm.cc:0485] >> admin_operation_cb:
'safSi=AmfDemo1,safApp=AmfDemo1', invocation: 60129542145, op: 7
Oct 29 17:18:39.173580 osafamfd [11367:imm.cc:0495] << admin_operation_cb
During first si-swap operation component faulted and invocationId was not
cleared by AMF.
So during second si-swap operation AMF used previous invocationId to respond to
IMM and it resulted in failure:
Oct 29 17:18:49 CON-PC osafimmnd[11282]: WA MDS Send Failed to service:IMMND
rc:2
Oct 29 17:18:49 CON-PC osafimmnd[11282]: ER Problem in sending to peer IMMND
over MDS. Discarding admin op reply.
Oct 29 17:18:49 CON-PC osafimmnd[11282]: WA Error code 2 returned for message
type 21 - ignoring
Oct 29 17:18:49 CON-PC osafamfd[11367]: NO safSi=AmfDemo,safApp=AmfDemo1 Swap
done
Attached log contains 214.tgz configuration and traces.
Attachment: 214.tgz (105.8 kB; application/x-compressed)
---
** [tickets:#214] amf: si-swap initiated on SI3 but received completion info
for SI2.**
**Status:** assigned
**Created:** Wed May 15, 2013 07:20 AM UTC by Praveen
**Last Updated:** Fri Sep 06, 2013 01:17 PM UTC
**Owner:** Praveen
Migrated from http://devel.opensaf.org/ticket/2945.
changeset : 3855
Model : 2n
configuration : 1App,1SG,2SU with 4comps each, 4SIs with 1csi each.
si-si deps configured as SI1<-SI2, SI1<-SI3, SI1<-SI4
Initially SU1 is active and SU2 is standby
scenario:
SI swap is done on SI3, COMP1 of SU1 is made to reject the quiesced assignment.
Due to which SI-swap would fail. Later again si-swap is initiated on same SI3.
SI-swap is initiated on SI3 but the completion status show for SI2.
/var/log/messages on SC-1 show
Dec 17 14:34:45 linux-xc76 osafamfd[9078]: NO safSi=SI3,safApp=test2nApp Swap
initiated—-> started on SI3
Dec 17 14:34:45 linux-xc76 osafamfd[9078]: NO Taking sidep action
si:'safSi=SI1,safApp=test2nApp', si_dep_state:'ASSIGNED'
Dec 17 14:34:45 linux-xc76 osafamfd[9078]: NO Taking sidep action
si:'safSi=SI2,safApp=test2nApp', si_dep_state:'ASSIGNED'
Dec 17 14:34:45 linux-xc76 osafamfd[9078]: NO Taking sidep action
si:'safSi=SI3,safApp=test2nApp', si_dep_state:'ASSIGNED'
Dec 17 14:34:45 linux-xc76 osafamfd[9078]: NO Taking sidep action
si:'safSi=SI4,safApp=test2nApp', si_dep_state:'ASSIGNED'
Dec 17 14:34:45 linux-xc76 osafamfd[9078]: NO safSi=SI2,safApp=test2nApp Swap
done———> completed on SI2
---
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.
------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
Opensaf-tickets mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
