- **status**: unassigned --> accepted
- **assigned_to**: Anders Bjornerstedt
- **Milestone**: future --> 4.5.FC
- **Comment**:

Will provide a solution that at least makes the distinction between resource 
abort and validation abort clear to the human user.




---

** [tickets:#744] IMM: Use error string to classify cause for aborted CCB.**

**Status:** accepted
**Milestone:** 4.5.FC
**Created:** Thu Jan 23, 2014 12:17 PM UTC by Anders Bjornerstedt
**Last Updated:** Wed Apr 30, 2014 06:57 AM UTC
**Owner:** Anders Bjornerstedt

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.
------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Opensaf-tickets mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

Reply via email to