- **status**: fixed --> accepted
- **Comment**:
Add support for enabling/disabling the new features tracked by this ticket
based on the opensafImmNostdFlags bit 5 for upgrades to OpenSAF 4.5
---
** [tickets:#799] IMM: Allow admin-operations directly targeting an
implementer/applier**
**Status:** accepted
**Milestone:** 4.5.FC
**Created:** Fri Feb 28, 2014 12:39 PM UTC by Anders Bjornerstedt
**Last Updated:** Thu May 08, 2014 11:45 AM UTC
**Owner:** nobody
The IMM service uses a mechanism called FEVS (Fake EVS) to achieve cluster
global synchronization of the IMM database at all nodes.
The best way for any cluster distributed application to be informed
(be synchronized with) changes to config data the application depends on,
is to use the applier interface (see the IMMSV README).
The main OI is of course not only informed of all changes but also controls
which changes are accepted or not by validating the changes.
The applier interface provides exactly the changed data contents and is FEVS
synchronized with the IMM RAM apply of that data at the processor where the
apply callback is received.
The applier interface provides both backwards and forwards synchrony.
That is the applier never receives a too early or a too late version of the
data,
they receive exactly the version/change done by a particular ccb(id) that was
has been successfully applied to the IMM.
The applier mechanism is scalable in terms of messaging. That is the applier
callback message is generated by the local IMMND co-located with the applier
at a processor. No inter-processor messaging or fevs broadcasting is done just
to support applier callbacks.
For reasons that are not fully clear, some applications still choose not to use
the applier mechanism and instead rely on the main OI for an application
to send a *message* to other parts of that application informing them that
a CCB has been applied. Presumably the send is triggered from the main OI
getting the apply callback. The idea is then that the receiving component
does its own local imm database lookup to find the relevant just applied
IMM data at the processor where the receiver resides.
The problem with this design is that the *message* sent from the main-oi apply
callback, to receivers located at *other* processors, typically does not go
via IMM-FEVS. Typically a plain direct MDS message is sent.
This design will can fail when the receiving process is located at a different
processor. The receiver will then read from the local IMM RAM in a way that is
not in FEVS synchrony with the apply of that particular CCB.
This means that the unsafe read (search/accessor) at the receiver will see an
applied state of imm data, but not necessarily for the particular CCB that
the sending OI apply-callback was related to.
The receiving/reading process may see an earlier state (if the non synchronized
MDS message arrives before the fevs-apply), or it may get lucky and see the
expected state (if the non synchronized MDS message arrives after the
fevs-apply); or it may even see a state where a subsequent CCB has overwritten
the expected ccb/state (if the non synchronized MDS message arrives after a
subsequent CCB has been applied).
For this reason there is a need for the IMM to provide an alternative messaging
service that is FEVS synhcronized. Such a mechanism already exists. It is the
admin-operation mechanism. An admin-operation request is always sent via fevs
so it is fevs synchronized at the receiver. The reply message for an admin-op
is sent via direct MDS, not over FEVS, but that is normally not a problem.
The only problem with using admin-operations as an FEVS RPC mehcnaism between
processes, is that it may be a bit cumbersome to set up. Not only does the
receiver have to be an OI, you also need to have some object the the OI is
registered to be the implementer for.
This enhancement proposes that it shall be allowed to use the existing
IMMA-OM side admin-operation interface, to generate an admin-operation
where the target is not any named imm-object, but a named implementer or
named applier.
The admin-operation will be sent to the named oi/applier and the existing
admin-operation callback will be invoked with the message from the sender.
This will then provide an easily accessible process to process RPC
mechanism that is FEVS synchronous.
Note however that we still recommend the applier interface for solving the above
problem. Using and admin-op will solve the most common backwards synchrony
problem. The OI needs to know the oi/applier-name for all receivers.
And unless the OI uses *synchronous* admin-operations to stay blocked
in the applycallback untill it gets the reply, the receiver is still
potentially vulnerable to forwards synchrony problem. This would be when
as subsequent CCB overwrites the CCB the receiver was supposed to read.
---
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
