- **status**: review --> fixed
- **Comment**:
default(4.6):
changeset: 6237:bec3c6601cb7
user: Hung Nguyen <[email protected]>
date: Tue Dec 23 14:48:03 2014 +0700
summary: imm: Return BAD_OPERATION for OiRtObject operations whith no
implementer [#1064]
changeset: 6238:875c52f93bbc
tag: tip
user: Hung Nguyen <[email protected]>
date: Tue Dec 23 15:06:40 2014 +0700
summary: imm: Update Runtime Objects Management test suite [#1064]
---
** [tickets:#1064] IMM: OiRtObject operations whith no implementer set should
return BAD_OPERATION**
**Status:** fixed
**Milestone:** 4.6.FC
**Created:** Thu Sep 11, 2014 10:40 AM UTC by Anders Bjornerstedt
**Last Updated:** Thu Jan 08, 2015 08:40 AM UTC
**Owner:** Hung Nguyen
It is currently the case that if a process:
1) Initializes an IMM-OI handle.
2) Has not set any implementer-name, i.e. has not yet (?) become any
identifiable OI.
3) Tries to use the oi-handle to create/delete/update runtime data.
Then the resulting error code returned will be ERR_BAD_HANDLE.
This is actually according to the SAF spec. But I claim this is both
inconvenient and a spec error.
Why is it a spec error ?
Well ERR_BAD_HANDLE should at least mean that the handle as such is bad,
i.e. unusable for whatever reason. That is the literal meaning of that error
code.
But in *this* error case discussed here the handle is actually not bad and
can even be used after this happens for e.g. saImmOiImplementerSet, i.e. to
associate an implementer-name with the handle, the lack of which was the cause
of this particlar problem.
The correct error code for this case I claim is ERR_BAD_OPERATION.
ERR_BAD_OPERATION -
The targeted object is not implemented by the invoking process
In contrast for ERR_BAD_HANDLE the SAF text is here self contradicting:
The handle immOiHandle is invalid, since it is corrupted, uninitialized,
has already been finalized, or is not associated with an implementer name.
The last clause 'not associated with an implementer-name' is a VALID state
for an OI handle that has been initialized but not associated with an
implementer-name! That is in fact the state of the handle demanded by
saImmOiImplementerSet. So it is not the handle that is invalid, but the
state of the (valid) handle that is not (yet) appropriate for RT operations.
The error code BAD_OPERATION (on the other hand) is defined for
saImOiRtObjectUpdate and saImmOiRtObjectDelete. Unfortunately SAF did not
specify that error code for saImmOiRtObjectCreate.
So this will be a *new* error code for saImmOiRtObjectCreate.
Fortunately there is not really any backwards compatibility issue for this
change of error code. The error case is an interface-vilolation, by definition
a surprise for the user/application. So it is actually acceptable, even
desirable (fail fast) for the client process to crash when this happens.
The client process has a bug.
An addition will be made to the "non compliance" section of the IMMSV_PR
and the IMMSV README to make this clear.
This new behavior is benign and better than the current behavior.
Yes it may be an unexpected error code for the application/user. But since
this is an interface violation (user/programmer error) the error case itself
is unexpected.
---
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.------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
vanity: www.gigenet.com
_______________________________________________
Opensaf-tickets mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
