Fault Tolerant Avatar
  1. OMG Specification

Fault Tolerant — Closed Issues

  • Acronym: FT
  • Issues Count: 9
  • Description: Issues resolved by a task force and approved by Board
Closed All
Issues resolved by a task force and approved by Board

Issues Descriptions

define the State as typedef any State

  • Key: FT-4
  • Legacy Issue Number: 3747
  • Status: closed  
  • Source: Eternal Systems ( Louise Moser)
  • Summary:

    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

  • Reported: FT 1.0b1 — Tue, 18 Jul 2000 04:00 GMT
  • Disposition: Resolved — FT 1.0
  • Disposition Summary:

    rejected

  • Updated: Fri, 6 Mar 2015 20:58 GMT

following question regarding modifications to CORBA core

  • Key: FT-3
  • Legacy Issue Number: 3516
  • Status: closed  
  • Source: Oracle ( Anita Jindal)
  • Summary:

    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.

  • Reported: FT 1.0b1 — Wed, 29 Mar 2000 05:00 GMT
  • Disposition: Resolved — FT 1.0
  • Disposition Summary:

    Remove OBJ_ADAPTER from this list.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

term "method" used wrongly

  • Key: FT-10
  • Legacy Issue Number: 4066
  • Status: closed  
  • Source: Credit Suisse ( Wolfgang Schulze)
  • Summary:

    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.

  • Reported: FT 1.0b1 — Mon, 20 Nov 2000 05:00 GMT
  • Disposition: Resolved — FT 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Harmful deprecation of LOCATE_FORWARD_PERM for Faut Tolerant CORBA

  • Key: FT-9
  • Legacy Issue Number: 3976
  • Status: closed  
  • Source: Alcatel-Lucent ( Julien Maisonneuve)
  • Summary:

    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.
  • Reported: FT 1.0b1 — Thu, 19 Oct 2000 04:00 GMT
  • Disposition: Resolved — FT 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

typedef issue

  • Key: FT-8
  • Legacy Issue Number: 3910
  • Status: closed  
  • Source: Eternal Systems ( Louise Moser)
  • Summary:

    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.

  • Reported: FT 1.0b1 — Mon, 25 Sep 2000 04:00 GMT
  • Disposition: Resolved — FT 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Encoding of Service Contexts in Fault Tolerant CORBA specification missing

  • Key: FT-7
  • Legacy Issue Number: 3908
  • Status: closed  
  • Source: Objective Interface Systems ( Victor Giddings)
  • Summary:

    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."

  • Reported: FT 1.0b1 — Mon, 25 Sep 2000 04:00 GMT
  • Disposition: Resolved — FT 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Propose Remove use of Filter

  • Key: FT-6
  • Legacy Issue Number: 3856
  • Status: closed  
  • Source: AT&T ( Robert Gruber)
  • Summary:

    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.

  • Reported: FT 1.0b1 — Wed, 13 Sep 2000 04:00 GMT
  • Disposition: Resolved — FT 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Issue with 'factory'

  • Key: FT-5
  • Legacy Issue Number: 3778
  • Status: closed  
  • Source: Eternal Systems ( Louise Moser)
  • Summary:

    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?

  • Reported: FT 1.0b1 — Mon, 21 Aug 2000 04:00 GMT
  • Disposition: Resolved — FT 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

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

  • Key: FT-11
  • Legacy Issue Number: 4109
  • Status: closed  
  • Source: Eternal Systems ( Louise Moser)
  • Summary:

    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"

  • Reported: FT 1.0b1 — Thu, 30 Nov 2000 05:00 GMT
  • Disposition: Resolved — FT 1.0
  • Disposition Summary:

    Correct the above statement with the revised text given below.

  • Updated: Fri, 6 Mar 2015 20:58 GMT