- **Milestone**: 4.5.FC --> future
- **Comment**:
We have not been able to reach a consensus on how to implement this.
My current stance is to provide a solution that at least tries to
makes the cause-class for the abort clear to the human operator.
A validation abort means there is no point in attempting a replay
of the same sequence of operations in a new CCB.
A resource abort means there may be a point in attempting a replay
of the same sequence of operations in a new CCB.
The error string message should make the cause class clear using
some form of prefix on the error string. Having a uniform prefix for
the cause class makes sense even if it is only interpreted by a human.
But it also *allows* a programmed application to probe this.
The only problem with the latter (a programmed discrimination
of the cause by the OM client software) is that we then have an
INTERFACE with all the issues that this implies. Documentation,
staying backwards compatible and perhaps most controversial:
would this be a *good* interface?
---
** [tickets:#744] IMM: Use error string to classify cause for aborted CCB.**
**Status:** unassigned
**Milestone:** future
**Created:** Thu Jan 23, 2014 12:17 PM UTC by Anders Bjornerstedt
**Last Updated:** Mon Mar 10, 2014 11:03 AM UTC
**Owner:** nobody
This is a special case of #58 (http://sourceforge.net/p/opensaf/tickets/58).
Enhancement #58 is a bit large and open-ended. This ticket focuses on a
particular need for complementary information about one error return code.
If a CCB related operation returns SA_AIS_ERR_FAILED_OPERATION it means that
the CCB has been aborted and the CCB-handle can no longer be used to generate
new (chained) CCBs.
The cause of the aborted CCB can be classified into two broad mutually exclusive
categories:
1) Logical errors related to the CCB buildup/contents. This would primarily
be validation errors where an OI rejects a ccb-operation or rejects
an apply.
2) Resource problems in the immsv. This could be the need for imm-sync that
gets priority over current non-empty CCBs that are not in critical. Or
it could be a "hung PBE" that gets restarted and finds the CCB did not
complete the commit, resulting in an abort. Or other reasons in immsv
or below.
Some applications that have the capability to record an attempted CCB at
the application level, may wish to attempt a replay of an aborted CCB,
but only if the CCB was aborted due to a cause in category (2).
One could refine this to distinguish within (2) between definitely transient
resource problems (imm sync) from likely stable resource limits (huge CCBs
that fail to commit over PBE). The latter are more likely to repeatedly fail.
But such refinement will not be done in this ticket.
The idea is to prefix the error string with an identifiable tag of some form.
The tag must be documented in the IMMSV README and the IMMSV_PR.
This would make it relatively simple for an application developer to write
code to match against the initial sub-string.
---
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.------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos. Get
unparalleled scalability from the best Selenium testing platform available.
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
Opensaf-tickets mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
