Comments on IMMSv_PR from AndersBj
a) Page 27. Sentence between points 8 and 9 says:
Some IMMA synchronous calls require OI processing, To avoid waiting for the
long timeout for each OI callback placed at IMMND server,
currently there is a hard-coded timeout of 6 seconds. The OI callback timeout
may be made configurable in future releases.
Configurable OI timeouts was implemented in 4.5 ticket #16.
b) Typo ‘earch’ should be ‘each’ on page 27.
c) Page 28 final sentence befoe section 2.2.8 is strange and wrong:
For error codes ERR_NO_RESOURCES, ERR_NO_MEMORY, ERR_BUSY,
the application has to try again at least once to know the exact changes
happened in the IMMND server.
First of all the application does not have to do anything here. These
return codes mean nothing was done.
So the application that gets these codes *knows* that nothing has
happened. In this sense they are the
Similar to TRY_AGAIN. The only difference with respect to TRY_AGAIN is
that the latter encourages retries
And the immsv “promises” that the turn around time for TRY_AGAIN is very
fast. TRY_AGAIN also means
That the cause of the block is known and managed by the IMMSV, while the
other three have causes
Outside of the immsv and the immsv has no control over their cause.
d) Page 40 and 41. The numbering of paragraphs is regular up to number 7.
But paragraph 7 then starts its own internal numbering with 1, 2 etc at the
same indentation level
Making the numbering hard to understand. Maybe use (a) (b) or (i) (ii) (iii)
etc as sub parapraph numbering ?
e) Page 44. One paragraph says:
A regular implementer name is persistent in the face of a cluster restart,
as long as it has been bound to at least one object.
But an applier name is not persistent in the face of a cluster restart,
regardless of whether it has been bound to anything.
The above used to be true but due to unreliability of implementer-name
persistence it was disabled in 4.3 by the immloader
Explicitly discarding the implementer-name.
(https://sourceforge.net/p/opensaf/tickets/543/)
Thus cluster restart drops implementer-names from release 4.3 and forward.
f) Page 79. Paragraph says:
For saImmOiRtObjectDelete if the parent name is greater
than 256 bytes length, and EXTENDED_NAMES is not enabled then
SA_AIS_ERR_INVALID_PARAM will be returned. In older releases (prior to 4.4),
SA_AIS_ERR_NAME_TOO_LONG is returned.
The term ‘parent name’ should be replaced by the term ‘root
name’. The same rule should reasonably apply to saImmOmCcbObjectDelete.
Operations of type delete are cascading so the provided name argument is a root
object fro that cascade.
---
** [tickets:#1371] imm: IMMSV PR update**
**Status:** unassigned
**Milestone:** 4.7-Tentative
**Created:** Wed May 13, 2015 09:33 AM UTC by Neelakanta Reddy
**Last Updated:** Mon May 18, 2015 10:45 AM UTC
**Owner:** Neelakanta Reddy
The following updates included in the IMM README, must be updated to IMMSV_PR
doc
1. #1347
2. #1107
---
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.------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Opensaf-tickets mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
