- Description has changed:
Diff:
~~~~
--- old
+++ new
@@ -1 +1 @@
-when implementer is disconnected (case where the OI application is died or
restarted (#1105)), then if there are Non-critical CCBs associated with this
implementer. Then those CCBs may be aborted in IMM, Because the final outcome
of these CCBs will be aborted.
+when implementer is disconnected (case where the OI application died or
restarted (#1105)), then if there are Non-critical CCBs associated with this
implementer. Then those CCBs may be aborted in IMM, Because the final outcome
of these CCBs will be aborted.
~~~~
- **Comment**:
The effect currently on the om-client is that when it eventually tries to
perform the next operation on that CCB then they will get
SA_AIS_ERR_FAILED_OPERATION, informing the OM client of the aborted CCB.
The effect on the OI trying to re-attach is that it gets TRY_AGAIN.
That is potentially more serious as we have seen with the AMF.
But the reason it is serious for the AMF is that the AMF to some extent
is designed to be fragile in relation to its OI role.
The fact that the AMF can not attach as OI should not inherently be a
blocker for the AMF, i.e. not a blocker for failover or switchover
or any primary AMF service in general. I beleive we can currently still
end up in cluster restart in some cases if OI attachment is not possible.
The only problem with a service not being able to attach as OI is that it
cant process CCBs or read requests on pure runtime attributes.
But neither of those tasks are primary or realtime critical.
The service should in this situation simply continue to provide the
primary service according to the *current* state of configuration data.
Runtime data is not readable for OM clients when OI is detached. But
again this is inconvenient but not fatal and certainly not improved
by restarting the cluster.
An open CCB that is neither aborted or committed is not something that
should interfere with anything in the primary services. The primary
service should continue according to current configuration. Only when
or if a configuration change commits is there any actual change in
configuration and only then should primary behaviour change.
This enhancement ticket should in principle be fixed to improve the
availability of OI functionality, i.e. CCB processing and pure RTA
responsiveness. Improving availability of second order functions is
not wrong.
But attaching as OI may still be blocked if the local IMMND is restarted.
We may provide an enhancement for fixing that too.
So making IMM services more available will of course make other services
more available in supporting configuration changes and runtime data
visibility.
But pleas dont use this ticket and a future fix of OI attachment over
empty local IMMND as an excuse for keeping primary service availability
dependent on OI attach availability.
---
** [tickets:#1391] imm: Abort the non-critical CCBs when implememnter is
disconnected**
**Status:** assigned
**Milestone:** future
**Created:** Mon Jun 22, 2015 06:45 AM UTC by Neelakanta Reddy
**Last Updated:** Mon Jun 22, 2015 01:14 PM UTC
**Owner:** nobody
when implementer is disconnected (case where the OI application died or
restarted (#1105)), then if there are Non-critical CCBs associated with this
implementer. Then those CCBs may be aborted in IMM, Because the final outcome
of these CCBs will be aborted.
---
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.
------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
_______________________________________________
Opensaf-tickets mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
