[tickets] [opensaf:tickets] #1740 amfd: unlock operation on SU gets timed out.
- **status**: review --> fixed - **Comment**: changeset: 7512:5cfe8ef6e9a0 branch: opensaf-4.6.x parent: 7503:75c1ab67a4e8 user:praveen.malv...@oracle.com date:Thu Apr 21 15:02:58 2016 +0530 summary: amfd: respond to IMM for admin op status when SG becomes stable [#1740] V2 changeset: 7513:48ee7b1a9048 branch: opensaf-4.7.x parent: 7504:c03230bc2689 user:praveen.malv...@oracle.com date:Thu Apr 21 15:03:43 2016 +0530 summary: amfd: respond to IMM for admin op status when SG becomes stable [#1740] V2 changeset: 7514:ba65587ecdcc branch: opensaf-5.0.x parent: 7510:eaed9e56314b user:praveen.malv...@oracle.com date:Thu Apr 21 15:04:00 2016 +0530 summary: amfd: respond to IMM for admin op status when SG becomes stable [#1740] V2 changeset: 7515:7849b56e6a89 tag: tip parent: 7511:f2530e22e758 user:praveen.malv...@oracle.com date:Thu Apr 21 15:04:13 2016 +0530 summary: amfd: respond to IMM for admin op status when SG becomes stable [#1740] V2 --- ** [tickets:#1740] amfd: unlock operation on SU gets timed out.** **Status:** fixed **Milestone:** 4.6.2 **Labels:** Admin op **Created:** Thu Apr 07, 2016 12:43 PM UTC by Praveen **Last Updated:** Tue Apr 12, 2016 05:23 AM UTC **Owner:** Praveen **Attachments:** - [imm.xml](https://sourceforge.net/p/opensaf/tickets/1740/attachment/imm.xml) (156.5 kB; text/xml) - [osafamfd](https://sourceforge.net/p/opensaf/tickets/1740/attachment/osafamfd) (1.1 MB; application/octet-stream) - [osafamfnd](https://sourceforge.net/p/opensaf/tickets/1740/attachment/osafamfnd) (687.6 kB; application/octet-stream) Applicable to all red models except NWAY. Appear in a special case when after cluster timer expiry unlock operation is invoked. Attached is imm.xml in which problem is simulated with NoRed model. About the application, in imm.xml one of the SU is kept in locked state. Steps to reproduce: 1) Bring up one controller up with the above configuration. 2) After cluster timer expiry, AMF will instantiate the SUs. Make sure that instantiattion of unlocked su get delayed so that enoug time is to issue a unlock on the locked su. 3) When component of unlocked is instantiating, issue unlock of locked SU. Now again make sure that response to the assignment is done after instantiation of unlocked su gets completed. 4) After instantiation of unlocked su, AMFd get response from AMFND for the admin operated SU and it gives assignment to newly instantiated SU and thus SG remains unstable. 5) Since in the second assignment it is not the SU that was being unlocked, AMF loses the context of admin operation and when SG becomes stable it never searches for any pending admin operation. 6) AMFD never respond to IMM for the completion of admin operation, Attached is the amfd log and amfnd log and imm.xml --- Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net 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.-- Find and fix application performance issues faster with Applications Manager Applications Manager provides deep performance insights into multiple tiers of your business applications. It resolves application problems quickly and reduces your MTTR. Get your free trial! https://ad.doubleclick.net/ddm/clk/302982198;130105516;z___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #1740 amfd: unlock operation on SU gets timed out.
- Description has changed:
Diff:
--- old
+++ new
@@ -10,19 +10,6 @@
5) Since in the second assignment it is not the SU that was being unlocked,
AMF loses the context of admin operation and when SG becomes stable it never
searches for any pending admin operation.
6) AMFD never respond to IMM for the completion of admin operation,
-Also there is one more problem since AMF does not respond to the admin
opeartion, it does not clear admin operation param in the SU. But when same SU
is tried for lock operation, AMFD allowed it. Actually AMFD is checking all the
other SUs in SG for any pending admin operation except for the SU for admin
operation request had come. The problem is with the check in su.cc
-
- /* Avoid multiple admin operations on other SUs belonging to the same SG. */
-for (auto const& su_ptr : su->sg_of_su->list_of_su) {
-/* su's sg_fsm_state is checked below, just check other su. */
-if ((su != su_ptr) && (su_ptr->pend_cbk.invocation != 0)) {
-report_admin_op_error(immoi_handle, invocation,
SA_AIS_ERR_TRY_AGAIN, nullptr,
-"Admin operation is already going on
(su'%s')", su_ptr->name.value);
-goto done;
-}
-}
-if condition should not include expression (su != su_ptr).
-
Attached is the amfd log and amfnd log and imm.xml
- **status**: accepted --> review
- **Comment**:
The other probelm is not there. In su_admin_op_cb(), AMFD is taking care of
returning TRY_AGAIN.
---
** [tickets:#1740] amfd: unlock operation on SU gets timed out.**
**Status:** review
**Milestone:** 4.6.2
**Labels:** Admin op
**Created:** Thu Apr 07, 2016 12:43 PM UTC by Praveen
**Last Updated:** Thu Apr 07, 2016 12:44 PM UTC
**Owner:** Praveen
**Attachments:**
- [imm.xml](https://sourceforge.net/p/opensaf/tickets/1740/attachment/imm.xml)
(156.5 kB; text/xml)
-
[osafamfd](https://sourceforge.net/p/opensaf/tickets/1740/attachment/osafamfd)
(1.1 MB; application/octet-stream)
-
[osafamfnd](https://sourceforge.net/p/opensaf/tickets/1740/attachment/osafamfnd)
(687.6 kB; application/octet-stream)
Applicable to all red models except NWAY.
Appear in a special case when after cluster timer expiry unlock operation is
invoked.
Attached is imm.xml in which problem is simulated with NoRed model.
About the application, in imm.xml one of the SU is kept in locked state.
Steps to reproduce:
1) Bring up one controller up with the above configuration.
2) After cluster timer expiry, AMF will instantiate the SUs. Make sure that
instantiattion of unlocked su get delayed so that enoug time is to issue a
unlock on the locked su.
3) When component of unlocked is instantiating, issue unlock of locked SU. Now
again make sure that response to the assignment is done after instantiation of
unlocked su gets completed.
4) After instantiation of unlocked su, AMFd get response from AMFND for the
admin operated SU and it gives assignment to newly instantiated SU and thus SG
remains unstable.
5) Since in the second assignment it is not the SU that was being unlocked, AMF
loses the context of admin operation and when SG becomes stable it never
searches for any pending admin operation.
6) AMFD never respond to IMM for the completion of admin operation,
Attached is the amfd log and amfnd log and imm.xml
---
Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net 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.--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #1740 amfd: unlock operation on SU gets timed out.
- **status**: unassigned --> accepted
- **assigned_to**: Praveen
---
** [tickets:#1740] amfd: unlock operation on SU gets timed out.**
**Status:** accepted
**Milestone:** 4.6.2
**Labels:** Admin op
**Created:** Thu Apr 07, 2016 12:43 PM UTC by Praveen
**Last Updated:** Thu Apr 07, 2016 12:43 PM UTC
**Owner:** Praveen
**Attachments:**
- [imm.xml](https://sourceforge.net/p/opensaf/tickets/1740/attachment/imm.xml)
(156.5 kB; text/xml)
-
[osafamfd](https://sourceforge.net/p/opensaf/tickets/1740/attachment/osafamfd)
(1.1 MB; application/octet-stream)
-
[osafamfnd](https://sourceforge.net/p/opensaf/tickets/1740/attachment/osafamfnd)
(687.6 kB; application/octet-stream)
Applicable to all red models except NWAY.
Appear in a special case when after cluster timer expiry unlock operation is
invoked.
Attached is imm.xml in which problem is simulated with NoRed model.
About the application, in imm.xml one of the SU is kept in locked state.
Steps to reproduce:
1) Bring up one controller up with the above configuration.
2) After cluster timer expiry, AMF will instantiate the SUs. Make sure that
instantiattion of unlocked su get delayed so that enoug time is to issue a
unlock on the locked su.
3) When component of unlocked is instantiating, issue unlock of locked SU. Now
again make sure that response to the assignment is done after instantiation of
unlocked su gets completed.
4) After instantiation of unlocked su, AMFd get response from AMFND for the
admin operated SU and it gives assignment to newly instantiated SU and thus SG
remains unstable.
5) Since in the second assignment it is not the SU that was being unlocked, AMF
loses the context of admin operation and when SG becomes stable it never
searches for any pending admin operation.
6) AMFD never respond to IMM for the completion of admin operation,
Also there is one more problem since AMF does not respond to the admin
opeartion, it does not clear admin operation param in the SU. But when same SU
is tried for lock operation, AMFD allowed it. Actually AMFD is checking all the
other SUs in SG for any pending admin operation except for the SU for admin
operation request had come. The problem is with the check in su.cc
/* Avoid multiple admin operations on other SUs belonging to the same SG. */
for (auto const& su_ptr : su->sg_of_su->list_of_su) {
/* su's sg_fsm_state is checked below, just check other su. */
if ((su != su_ptr) && (su_ptr->pend_cbk.invocation != 0)) {
report_admin_op_error(immoi_handle, invocation,
SA_AIS_ERR_TRY_AGAIN, nullptr,
"Admin operation is already going on
(su'%s')", su_ptr->name.value);
goto done;
}
}
if condition should not include expression (su != su_ptr).
Attached is the amfd log and amfnd log and imm.xml
---
Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net 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.--
___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #1740 amfd: unlock operation on SU gets timed out.
---
** [tickets:#1740] amfd: unlock operation on SU gets timed out.**
**Status:** unassigned
**Milestone:** 4.6.2
**Labels:** Admin op
**Created:** Thu Apr 07, 2016 12:43 PM UTC by Praveen
**Last Updated:** Thu Apr 07, 2016 12:43 PM UTC
**Owner:** nobody
**Attachments:**
- [imm.xml](https://sourceforge.net/p/opensaf/tickets/1740/attachment/imm.xml)
(156.5 kB; text/xml)
-
[osafamfd](https://sourceforge.net/p/opensaf/tickets/1740/attachment/osafamfd)
(1.1 MB; application/octet-stream)
-
[osafamfnd](https://sourceforge.net/p/opensaf/tickets/1740/attachment/osafamfnd)
(687.6 kB; application/octet-stream)
Applicable to all red models except NWAY.
Appear in a special case when after cluster timer expiry unlock operation is
invoked.
Attached is imm.xml in which problem is simulated with NoRed model.
About the application, in imm.xml one of the SU is kept in locked state.
Steps to reproduce:
1) Bring up one controller up with the above configuration.
2) After cluster timer expiry, AMF will instantiate the SUs. Make sure that
instantiattion of unlocked su get delayed so that enoug time is to issue a
unlock on the locked su.
3) When component of unlocked is instantiating, issue unlock of locked SU. Now
again make sure that response to the assignment is done after instantiation of
unlocked su gets completed.
4) After instantiation of unlocked su, AMFd get response from AMFND for the
admin operated SU and it gives assignment to newly instantiated SU and thus SG
remains unstable.
5) Since in the second assignment it is not the SU that was being unlocked, AMF
loses the context of admin operation and when SG becomes stable it never
searches for any pending admin operation.
6) AMFD never respond to IMM for the completion of admin operation,
Also there is one more problem since AMF does not respond to the admin
opeartion, it does not clear admin operation param in the SU. But when same SU
is tried for lock operation, AMFD allowed it. Actually AMFD is checking all the
other SUs in SG for any pending admin operation except for the SU for admin
operation request had come. The problem is with the check in su.cc
/* Avoid multiple admin operations on other SUs belonging to the same SG. */
for (auto const& su_ptr : su->sg_of_su->list_of_su) {
/* su's sg_fsm_state is checked below, just check other su. */
if ((su != su_ptr) && (su_ptr->pend_cbk.invocation != 0)) {
report_admin_op_error(immoi_handle, invocation,
SA_AIS_ERR_TRY_AGAIN, nullptr,
"Admin operation is already going on
(su'%s')", su_ptr->name.value);
goto done;
}
}
if condition should not include expression (su != su_ptr).
Attached is the amfd log and amfnd log and imm.xml
---
Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net 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.--
___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
