Issues for Fault Tolerance FTF Mailing List

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 3516: following question regarding modifications to CORBA core
Issue 3747: define the State as typedef any State
Issue 3778: Issue with 'factory'
Issue 3856: Propose Remove use of Filter
Issue 3908: Encoding of Service Contexts in Fault Tolerant CORBA specification missing
Issue 3910: typedef issue
Issue 3976: Harmful deprecation of LOCATE_FORWARD_PERM for Faut Tolerant CORBA
Issue 4066: term "method" used wrongly
Issue 4109: On page 27-9 of the FT CORBA spec, under "Application-Controlled Membership

Issue 3516: following question regarding modifications to CORBA core (ft-ftf)

Basically, the Failure OBJ_ADAPTER is considered a failover condition in the 
document that was sent out.  In most cases OBJ_ADAPTER exception may be thrown 
when there is an internal ORB error.  In case of an internal ORB error, the 
retry on the TAG_ALTERNATE_IIOP_ADDRESS may still yield the same exception. This 
may be inefficient.  Do you see situations where doing a failover on this 
particular exception is useful.

The Fault Tolerant CORBA specification defines the State used by the
get_state(), set_state(), get_update(), set_update() methods, as

   typedef sequence<octet> State

Those methods must be implemented by the application programmers.  
They will find their task easier if we define the State as:

   typedef any State

The Fault Tolerant CORBA specification contains the following struct.

  struct FactoryInfo 
  {
       GenericFactory factory;
       Location the_location;
       Criteria the_criteria;
  };

This causes a problem for the IDL compilers of some vendors, because
"factory" is a keyword in CORBA V2.3.  See CORBA V2.3, page 3-8, Lexical
Conventions, June 1999.

We need to change "factory" in this struct to "fact", "fctry",
"generic_factory", or whatever.  What is your preference?

Motivation: The Notifier will be easier to replicate if it is a single
object.  At present, all Filters created by the Notifier must also be
replicated.  Furthermore, there is no requirement that a Filter be destroyed
by the client that created it (once it is done using it), raising a garbage
collection issue.  FOr a connected consumer, if the consumer no longer
exists the Notifier can discard the connection.  There is no analagous test
for Filters.

The Notifier interface is already a collapsed version of multiple
CosNotification APIs to get rid of the channel/admin/proxy objects in favor
of one object, so I am just proposing we carry through on that approach.


Óne proposal:

First, remove method create_subscription_filter.

Second, change the 2 connect_foo_fault_consumer methods
(connect_structured_fault_consumer + connect_sequence_fault_consumer) to
take just a consumer and a grammar:
  ConsumerId connect_foo_fault_consumer (in CosNotifyComm::FooPushConsumer,
                                         in string constraint_grammar)
 raises (ÏnvalidGrammar, AlreadyConnected)

One or more event forwarding constraints is associated with each connected
consumer, with the default being a constraint that matches all events.  The
ConsumerID  returned from a  call can be passed into methods that modify
these constraints.  When a consumer is disconnected, the associated
constraints are discarded.

Third add methods for manipulating constraints associated with a ConsumeID:

  string constraint_grammar(in ConsumerID)
  void add_constraints(in ConsumerID, ...)
  void remove_constraints(in ConsumerID, ...)
  void remove_all_constraints(in ConsumerID)
  void modify_constraints(in ConsumerID, ...)
  ConstraintExpSeq get_constraints(in ConsumerID)

where ... means the normal arguments that are in the corresponding methods
in the Filter spec.

The above methods correspond to the Filter methdos that are required in the
current version of the spec, except I left out 2 of them, match_structured
and destroy.  I do not think we need to support match_structured -- only the
Notifier needs to be able to do matching.  destroy is not needed because
there is no filter object to be destroyed.  (disconnect is sufficient.)

ALTERNATE PROPOSAL

A simpler scheme is to associate a single constraint with each consumer.
This is not very restrictive, especially when you consider that there is
currently only one event type in use in the FT spec.  The default would
still be a constraint that matched all events.  In this case the only method
needed to modify this constraint is:

void replace_constraint(in ConsumerID,
                        in EventTypeSeq event_types,
                        in string constraint_expression)

Further, if we are willing to stick to the default constraint grammar, no
grammar needs to be specified, which simplifies connect_foo_consumer -- not
only by removing the constraint_grammar argument but also by removing the
InvalidGrammar exception, which comes from CosNotifyFilter.  I believe one
could simplify things enough to get rid of any dependencies on
CosNotifyFilter.  It is not clear how important this is, but I thought I
should mention the possibility.

13.6.7 of the CORBA 2.3 specification states: "The context data for a particular service will be encoded as specified for its service-specific OMG IDL definition, and that encoded representation will be encapsulated in the context_data member of IOP::ServiceContext. (See Section 15.3.3, Encapsulation, on page 15-13)."

The descriptions of service contexts in the FT spec are missing an explicit statement of the encoding of the service context data.

Proposed Resolution:

Add the following sentence in all appropriate sections: "When encoded in a request or reply message header, the <code>context_data</code> component of the <code>ServiceContext</code> struct will contain a CDR encapsulation of the xxxxxx struct."

One additional issue I have is that the
ReplicationStyleValue, MembershipStyleValue, ConsistencyStyleValue,
FaultMonitoringStyleValue, FaultMonitoringGranularityValue 
are typedefed to long, whereas the 
InitialNumberReplicasValue and MinimumNumberReplicasValue 
are typedefed to unsigned short.  It might be more appropriate
to typedef all of these to unsigned short.

Earlier this year, the interop FTF deprecated the LOCATE_FORWARD_PERM
exception because of several reasons :
- it was badly specified
- it made the implementation of hash() difficult, and broke most of the
  existing ones.

It turns out that the Fault Tolerance specification published a little
earlier crucially requires a similar mechanism.
In normal life, most applications can rely on plain LOCATE_FORWARD because
there is no reason to expect the death of the originally pointed component.
In the case of Fault Tolerant CORBA, this is entirely different: it is
precisely when we issue a LOCATE_FORWARD_PERM that we know for sure that
the original component is dead, and might never return. If all the backup
profiles of an IOR enjoy the same death, all hope is gone.

This means that without a mechanism similar to LOCATE_FORWARD_PERM, the
Fault Tolerant CORBA spec cannot address the requirements of real
fault-tolerant systems.

This is why the Fault-Tolerant CORBA FTF would like to see LOCATE_FORWARD_PERM
re-introduced in some way. Here are a few ideas that might help :

Issue of scope:
The scope of LOCATE_FORWARD_PERM is ORB lifetime.

Issue of hash() :
Let us be reminded that the Fault-Tolerant CORBA spec defines teh concept of
an Interoperable Object Group Reference (IOGR). The IOGR contains a specific
profile that contains a group identifier.
- When an ORB receives and IOGR, it should compute the value of hash() based
  on the GroupID contained in the IOGR, and performs LOCATE_FORWARD_PERMs if
  requested.
- When an ORB receives a normal IOR (i.e. an IOR lacking a group profile) it
  computes hash() in the customary way, and doesn't have to respond to
  LOCATE_FORWARD_PERMs.

Throughout the document, the authors use the term "method" several times where they should be talking about "operations" instead. This violates the general understanding of the OMG terminology, where IDL interfaces contain "operations", not "methods". The term "method" is usually reserved as a concept of oo programming languages. 

I recommend that for the next revision, the authors run a global search&replace and identify where they want to talk about methods and where of operations. 

On page 27-9 of the FT CORBA spec, under "Application-Controlled Membership",

"The application-controlled (MEMB_INF_CTRL) Membership Style"

should be corrected to read

"The application-controlled (MEMB_APP_CTRL) Membership Style"