Issues for Messaging RTF mailing list

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

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

Issue 1613: QoS Policy values in compliance chapter
Issue 1666: 6.8.3.1 C++ Example of Generated Poller
Issue 2263: reply handler object in the AMI model
Issue 2352: Errant Messaging::Timeout
Issue 2353: Issue: create_policy explanation
Issue 2356: Poller may only be used in ORB that created it
Issue 2500: The Messaging specification mentions QueuedDeliveryPolicy twice
Issue 2506: wording changes in AMI section 3.3.2
Issue 2536: Establish set of REBIND exceptions
Issue 2537: TIMEOUT system exception not mentioned in section 5.3.4
Issue 2538: TIMEOUT system exception issue
Issue 2581: set_policy_overrides" operation defined twice
Issue 2627: Semantics of RoutingPolicy with synch. invokes?
Issue 2628: DII, callbacks, and exception holders
Issue 2630: SYNCH_WITH_SERVER issue
Issue 2637: Policy Manager and Policy Current
Issue 2659: On page 59 (Section 6.4.1), ExceptionHolder
Issue 2765: RequestHeader response_flags unclear
Issue 2802: Support for polling in arrival order is needed
Issue 2803: Support of some form of correlation identification is needed
Issue 2811: Callback exception handler has potential name-clash
Issue 2812: Callbacks cannot be implemented using DSI
Issue 2878: 6.6.4 is_from_poller (issue 01)
Issue 2879: 6.6.4 is_from_poller (issue 02)
Issue 2929: Removing type specific exception holder" and detail changes
Issue 3049: Only righteous object as reply handler supported
Issue 3050: Awkward way of unmarshaling exceptions
Issue 3051: Async. methods for given interface all grouped in one reply handler class
Issue 3052: CORBA::PollableSet::poll and CORBA::Poller::is have same semantics
Issue 3053: In polling modelreturn value in a reply is not returned as return value
Issue 3054: messaging issues: name clashes from implied IDL
Issue 3059: messaging issue: unchecked narrow too constrained
Issue 3071: messaging issue: pollable sets broken
Issue 3077: is_from_poller shoud raise no exception
Issue 3082: local interface PollableSet: why?
Issue 3218: Wrong policy names
Issue 3300: DIIPollable also needs to be an abstract valuetype like Pollable.
Issue 3540: Is there an ORB Policy Manager and a Policy Current?
Issue 3542: Section 6.5 "Type Specific ReplyHandler Mapping (formerly issue 2534)
Issue 3543: PersistentRequest::get_reply -- read once, or read many (formerly issue2163
Issue 3544: Inheritance of ExceptionHolders (formerly issue 2658)
Issue 4012: Precedence of propagated policy values

Issue 1613: QoS Policy values in compliance chapter (messaging-rtf)

Summary: The compliance chapter needs to clarify which (if any) QoS Policy values
 must be supported by a compliant implementation.
 

As per discussion at face to face meeting a while back, the compliance statement was felt to be sufficient. 
     Quoting Section B.1 (which should be editorially moved somewhere else) 

     In order to be conformant with this specification, the following mappings and features must be supported and
     implemented using the specified semantics : 
     ..... 
     Quality of Service Policies for Messaging. These new Policies and their possible values are described in
     "Messaging Quality of Service" on page 1-2 

     Implementation of the following component is not required to be conformant with this specification : 

     Time Independant Invocations (TII). This component includes the QoS Policy that supports TII(Queued Devliery
     Policy), the typed PersistentPollers described in Persistent Type Specific Poller on page 1-28, and all
     interoperable Routing interfaces described in "Message Routing Interoperability" on page 1-44 

     Close this issue. 

Summary: Issue Summary:  Update Messaging specification for compliance with 
 Objects by Value RTF 1.1 report.
 
 Issue Detail: The specification syntax and example generated code 
 for using Objects by Value is at best compliant with the OBV 1.0 spec,
 and in some cases would need revision for compliance with that
 specification.  Update the spec to be compliant with the ObV
 RTF intended for publication in CORBA 2.3.
 
 

1) Change all editorial mentions of value (in the context of OBV) to valuetype. I started to enumerate these but had got to about 15 instances in 2 pages, and got fed up. I hope the RTF will indulge us to make such such a proposal. 

2) Change all mentions of the keyword value in IDL to the keyword valuetype. 

3) Change the definition of Generic Exception Holder in section 6.4.1 from 

module Messaging { 
        value ExceptionHolder { 
                boolean is_system_exception; 
                boolean byte_order; 
                sequence<octet> marshaled_exception; 
        }; 
}; 

to 

module Messaging { 
        typedef sequence <octet> octSeq; 
        valuetype ExceptionHolder { 
                private boolean is_system_exception; 
                private boolean byte_order; 
                private octSeq marshaled_exception; 
        }; 
}; 

4) The definition of Generic Poller Value in Section 6.6 has already been "nearly" fixed in the resolution to Issue 3071. The only thing remaining is to make the data private. Change from 

module Messaging { 
        valuetype Poller : CORBA::Pollable { 
                readonly attribute Object operation_target; 
                readonly attribute string operation_name; 
                attribute ReplyHandler associated_handler; 
                readonly attribute boolean is_from_poller; 
                Object target; 
                string op_name; 
        }; 
}; 

to 

module Messaging { 
        valuetype Poller : CORBA::Pollable { 
                readonly attribute Object operation_target; 
                readonly attribute string operation_name; 
                attribute ReplyHandler associated_handler; 
                readonly attribute boolean is_from_poller; 
                private Object target; 
                private string op_name; 
        }; 
}; 

5) Make the corresponding changes in the consolidated IDL. 

6)  Change code examples to be conformant with the language mapping for valuetypes 

Summary: It does not appear to be clear in the AMI model whether in a non
 TII mode, a reply handler object can be one outside the process
 which issued the AMI request.
 
 For example, in section 3.3.1 AMI Components
 
 ReplyHandler - A ReplyHandler is an Object which encapsulates the functionality
 for handling an asynchronous reply. It is used for callback model reply handling.
 
 
 and then in section 3.3.2 TII Components
 
 Persistent Reply Handler - A ReplyHandler whose Object reference is created
 by a POA with a PERSISTENT LifeSpan Policy. The Persistent Reply Handler
 may be implemented by a process other than the one that issued the request.
 
 

It is sufficiently clear that a reply handler can be outside the process whch issued the AMI request. Close this issue. 

Summary: The typedef for Messaging::Timeout is never used
 in the rest of the specification.
 
 Proposed Resolution:  The typedef was errantly left into
 the specification but is never used.  It should be
 deleted from the IDL in section 5.3 and the summary
 IDL in 10.3.
 

Summary: Issue:  The definition of ORB::create_policy has led to some
 confusion.  Clarify how specifications can make
 use of this operation.
 

This issue, along with Jon Goldberg's proposed resolution has 
already been resolved.  The proposed text now resides in section 4.8.5 of 
the 2.4 CORBA Spec.  Close the issue 

Summary:  The non-persistent Poller valuetype may not be passed
 from the originating client to some other client.  Only
 Persistent Poller valuetypes may be used in this way.
 

This is pretty clear already, but to further clarify, add the following words in section 1.3.6 of the output of Messaging 1.2 RTF at the end of the second sentence  : 

A basic generated Poller cannot be used outside the client that invoked the sendp_ operation which resulted in its creation. 

Summary: The Messaging specification mentions QueuedDeliveryPolicy twice: 
 First in the introductory section which claims that this policy 
 triggers time-independent invocation, and second in the 
 compliance section 8 that mentions it as "the QoS policy that 
 supports TII". It doesn"t appear anywhere else, including in the 
 IDL. Presumably it was replaced elsewhere by 
 ROUTE_STORE_AND_FORWARD. These two spots should be changed to 
 reflect this. 
 

The Messaging specification mentions QueuedDeliveryPolicy twice 
One of the sections of text mentioned in this issue is still 
present.  In section C.1 of the 2.4 Messaging Spec, we still refer to the 
QueuedDeliveryPolicy. This should be changed (editorially, or with a vote) 
to be RoutingTypePolicy.

The following wording changes are needed in Section 3.3.2: In the first sentence, change "to support interoperability and Time Independent Invocations" to "to support interoperability of Time Independent Invocations". and in the second sentence of the first bullet, change "deferred synchronous" to "asynchronous".

Summary: 1) In the specification, settings of the REBIND policy of 
 NO-REBIND or NO_RECONNECT are supposed to alert clients to 
 possible changes of policy of servants established at a different 
 location than originally bound. But, since servants may be 
 established on different POAs on the same server, or even on a 
 different server that shares a connection with the original 
 server, this policy is weak protection against QoS policy change. 
 Isn"t connection orthogonal to policy: a new connection may not 
 result in a policy change, and a maintained connection may invoke 
 a servant with a new set of policies anyhow. 
 
 Either the specification should establish a set of REBIND 
 exceptions that strongly couple to policy change, or the weakness 
 of the current set should be explained in section 5.3.1. 
 
 

Summary: 2) The TIMEOUT system exception is defined in 5.2.2.3. It is 
 actually used in the policies defined in sections under 5.3.4, 
 but never mentioned there. It should be mentioned in those 
 sections where it applies, and its actions clarified but see the 
 following related issue. 
 

this issue has been resolved.  The text no longer refers 
to a Messaging:TIMEOUT exception.  It does use CORBA:TIMEOUT, but does not 
(re)define it.  It is defined in 4.11.3.33 of the 2.4 Spec.  Close the 
issue. 

Summary: 3) The definition of the TIMEOUT system exception says that it is 
 raised "when no delivery has been made and the specified 
 time-to-live period has been exceeded." It does not specify 
 delivery of requests or replies specifically, so presumably it 
 applies to both. It is not easy to see what it means to require 
 generation of a TIMEOUT exception for a reply that has been 
 processed but delayed on the network. What raises the exception? 
 Does a router replace the response with the exception? This seems 
 to be out of scope for router behavior. Does the ORB of the 
 client or ReplyHandler replace the response with the exception 
 before delivering it? Possibly the intent was to allow delayed 
 responses to be dropped; at least this avoids cluttering the 
 network with obsolete packets but the wording of the section does 
 not allow this. This needs to be clarified. 
 

Not clear what is being requested. Specific sections of AMI define when 
TIMEOUT is to be raised. It does leave a lot of freedom for the implementor to decide 
when to actually raise this exception. Indeed there are significant quality of implementations 
issues involving proper design of asynchronous invocation systems. it is not clear what 
more needs to be said in a standard specifciation. 

Summary: The Messaging::PolicyManager interface 
 defines a "set_policy_overrides" operation,
 but this operation is also defined in 
 the CORBA::Object interface.
 
 IDL prohibits the redefinition of an
 operation in derived interfaces, this may not
 apply in this case because CORBA::Object is
 a pseudo-object.
 
 Still, in C++ this operation names result in
 ambiguities because both have the same
 parameters but different return values.
 
 

The names of Object pseudo operations are not in the name space of IDL 
operations, hence there is no clash. Even in the C++ mapping the Object pseudo operations 
are name-munged with a _ prefix to ensure that they do not clash with real IDL defined 
operation names 

Summary: The Messaging spec defines the RoutingPolicy as controlling whether or not
 requests are sent over a Router.  Is this policy only intended for asynchronous
 method invocations, or is intended to apply to all invocations?  If the latter,
 then how should synchronous invocations be sent over a Router?
 
 I"d suggest that this policy applies only to requests sent using polled or
 callback dispatching.
 

Summary: Callback-style invocations use an exception holder valuetype to report
 exceptions to the callback.  The name (and presumably the RepositoryID) of this
 exception holder valuetype is generated by the IDL compiler, and derived from
 the name of the target interface.
 
 When sending a callback-style invocation over the DII, there is no way for the
 ORB to determine the RepositoryID since the name of the target interface is not
 available (in fact, the RepositoryID of the target interface is not available). 
 This makes it impossible for the ORB to report exceptions, as the repository ID
 must be sent with the exception holder in the callback to allow the ORB to
 create the appropriate valuetype.  
 

The description of the SynchScope policy of SYNCH_WITH_SERVER states that "the server-side ORB shall send a reply before invoking the target implementation." Because the target operation may be responsible for setting up the argument list (e.g. in DSI), this means that we lack any information about the request arguments at the time the response is sent. For methods declared oneway in IDL, this is well and good -- the method signature can only contain input parameters, and thus the response message will always be empty, and can be generated without type information. However, the DII allows an application to send a request oneway even if it does contain outs, inouts, return values, which would require the server to process the request in order to properly generate a response.

In section 15.4.2.1, the description of response_flags describes how if the operation is declared oneway, or if it is invoked with DII with INV_NO_RESPONSE, the response flags can be set to either 0x1 (result of setting SYNC_WITH_SERVER) or 0x0 (result of setting SYNC_WITH_TRANSPORT or SYNC_NONE).  If set to 0x1 for a oneway operation, receipt of a reply does not imply that the operation has necessarily completed. 

2 way requests will have the flag set to 0x3 so I think that if the response_flags is set to 0x1, then the 
non-exceptional reply body should be empty (i.e. the equivalent of void return with no out/inout parameters). 
There are no backwards compatibility problems here since 1.1 or 1.0 servers will not receive a 1.2 request 
message. 

Therefore, add after second sentence in response_flags bullet, 

A non exception reply to a request message containing a response_flags value of 0x1 should contain an empty body, i.e. the equivalent of a void operation with no out/inout parameters. 

Summary: In keeping with the general approach of moving things into their own
 modules and out of the CORBA module to allow ease of independant
 evolution etc. I would like to propose that the PolicyManager and
 PolicyCurrent interfaces be moved out of the CORBA module into their own
 module called perhaps PolicyManagement or some such. This sort of
 partitioning makes it easier to deal with versioning issues related to
 inclusion of parts of CORBA in JDK etc.
 
 Coming to think of it, perhaps, eventually, all Policy factory related
 operations, ORB::create_policy comes to mind, should be moved into their
 own PolicyFactory interface and placed in the PolicyManagement module,
 but for now it can stay where it is. For obvious reasons the
 CORBA::Policy interface and the Object operations related to Policy need
 to remain where they are for now.
 

Summary: On page 59 (Section 6.4.1), ExceptionHolder is defined as follows:
 
 //IDL
 module Messaging {
    // ... all the other stuff
    value ExceptionHolder {
      boolean is_system_exception;
      boolean byte_order;
      sequence<octet> marshaled_exception;
   };
 };
 
 This definition requires that the generated <typed>ExceptionHolder
 unmarshal the marshaled_exception twice: once to get the repositoryId
 for the exception, and once to actually read the exception.  While this
 can be done (easily in our case since our implementation of InputStream
 has "get/setPosition()" methods), it seems that including a field with
 the repository id would make portability easier.
 
 On a larger scope, this entire mechanism will add the need to _generate_
 code that can unmarshal both system and user exceptions OR it will
 require a language-mapping specific extension to
 Messaging::ExceptionHolder that allows it handle the SystemException
 case.  In either case, I think we should clarify this in the spec.  As
 it stands, ExceptionHolder has no specified behaviour, only state.  If
 we expect portable generated code, we need to specify just what
 compilers can expect of the ExceptionHolder.
 
 As far as the Messaging Spec itself, I would suggest the following text
 be added after the first paragraph of section 6.4.1:
 
 "Each language mapping will provide a mechanism for type specific
 subclasses of ExceptionHolder to obtain any raised SystemExceptions
 without requiring the subclass to unmarshal the marshaled_exception
 field.  Additional support for raising UserExceptions may also be
 provided."
 
 In the case of Java, I would suggest the following method be added to
 the implementation of Messaging::ExceptionHolder:
 
     public void raise_exception() throws org.omg.CORBA.SystemException,
 org.omg.CORBA.portable.ApplicationException;
 
 

I dont believe the problem here is a significant one, and doesnt justify duplicating the repository id 
information. In the simplest case, the GIOP reply message has just returned from the server to the 
local client address space where the callback also is, and so to get the repository id of the 
system exception out of the GIOP message would require parsing of it twice anyway. 
Close this issue.

In 15.4.1.2 section on RequestHeader, the description of response_flags (new for GIOP 1.2) is unclear: A value of \x01 indicates that the client does not expect to receive a response containing values of output arguments and return value, but does wish to receive some sort of reply; the reply may be sent before the request is complete. What is the server expected or permitted to send in this case if there are no exceptional conditions to report? Must it send a ReplyMessage containing values for the arguments defined by the interface? Or may/must it send a ReplyMessage consistent with an operation that has no arguments and return values? If the server returns a reply containing return values and/or output arguments, are these to be visible to the caller, or may/must they be hidden from the caller? If such a reply is sent prior to the completion of the request by the server, is there any guidance regarding what values should be returned?

 1. The fact that the receiving of replies and the matching of replies to the corresponding requests is hard-wired represents a serious limitation for TII. Support for polling in arrival order is needed.

I dont really understand the problem here. One always has a different poller for each sendp request sent, and one can poll each of them in turn for a finite or even 0 time. One even has a construct such as PollableSet to make it easy to go around a number of pollers. 
Close this Issue. This appears to require a very significant change to the specification 
to support a usage pattern that appears to have not been part of the original adopted 
specification. It seems that this sort of a change could perhaps have been admissible 
in the first R/FTF, but seems out of scope for a subsequent RTF. Propose closing no change

 2. There is a lack in providing support for correlating requests and replies in the case of TII. Support of some form of correlation identification is needed.

a)    - the generated, persistent type-specific pollers have a private state member 
            of type MessageRouting::PersistentRequest; change it to public access 
        - introduce initializers on the persistent type-specific pollers 
b)    - define correlation id as a string of opaque content 
        - introduce a correlation id attribute on CORBA::Poller 
        - introduce initializers on persistent type-specific pollers 
c)    - Close this issue 
Proposed Resolutions 
a) -------------------------------------------------------------- 
The following changes are referring to document ptc/00-02-05. 

p. 1-26, change 

"1.3.6 Type-Specific Poller Mapping 
The polling model requires usage of generated type-specific Poller values.A value is used because all operations are locally implemented. The basic generated Poller encapsulates the operations for obtaining replies to an outstanding asynchronous request. A derived PersistentPoller value also adds private state that allows the response to be obtained from a client other than the client that made the request. This private state is used by the PersistentPoller implementation in conjunction with the messaging-aware ORB." 

to read 

" 1.3.6 Type-Specific Poller Mapping 
The polling model requires usage of generated type-specific Poller values. A value is used because all operations are locally implemented. The basic generated Poller encapsulates the operations for obtaining replies to an outstanding asynchronous request. A derived PersistentPoller value also adds public state and initializers that allows the response to be obtained from a client other than the client that made the request. This public state is used by the PersistentPoller implementation in conjunction with the messaging-aware ORB." 
  

p. 1-28, change 

"1.3.6.2 Persistent Type-Specific Poller 
When Time-Independent Invocations are made, the reply may be obtained by a different client than the one that made the original request. An instance of persistent poller is returned from such invocations. The PersistentPoller contains the state necessary to allow polling to be performed in a client distinct from the one that made the request. This state is used privately by the messaging-aware ORB and is not directly accessible to the application. 

The generated PersistentPoller value is derived from the basic one. It adds no methods, only one piece of private state. For an interface named ifaceName the following PersistentPoller is generated: 

    value AMI_<ifaceName>PersistentPoller : AMI_<ifaceName>Poller { 
        MessageRouting::PersistentRequest outstanding_request; 
    }; 

Just as with any CORBA value this PersistentPoller can be passed as an argument to IDL operations and a copy of the Poller will be instantiated local to the callee." 

to read 

"1.3.6.2 Persistent Type-Specific Poller 
When Time-Independent Invocations are made, the reply may be obtained by a different client than the one that made the original request. An instance of persistent poller is returned from such invocations. The PersistentPoller contains the state necessary to allow polling to be performed in a client distinct from the one 
that made the request. This state is used by the messaging-aware ORB. It is also made directly accessible to the application such that it can be used to save it in a persistent store and initialize PersistentPoller values in a different client. 

The generated PersistentPoller value type is derived from the basic one. It adds no methods, only one piece of public state and an initializer. For an interface named ifaceName the following PersistentPoller is generated: 

    valuetype AMI_<ifaceName>PersistentPoller : AMI_<ifaceName>Poller { 

        public MessageRouting::PersistentRequest outstanding_request; 

        factory init(in MessageRouting::PersistentRequest outstanding_request); 
    }; 

This PersistentPoller can be instantiated by the application by providing the value of the outstanding_request state member of the persistent poller returned from a Time-Independent Invocation. For optimisation reasons, it is not required that PersistentPoller instances that are created via the initializer will have the target and op_name members initalized with the values from the original request upon creation. 

This PersistentPoller can also be passed as an argument to IDL operations and a copy of the Poller will be instantiated local to the callee. Note that the IDL operation must use the generic Poller or Pollable type for the parameter because type-specific pollers are only defined in implied-IDL." 
  

p. 1-99, change 

"A client uses the Poller in a similar fashion as in the DII deferred synchronous model. The programmer can at any time choose to check whether or not the reply has arrived and deal with it in the current programming context. The user may also ask a Poller to block until the reply has arrived. The PersistentRequest reference is not visible to the client application, but is specified to enable interoperability between Messaging products. 

When a Time-Independent Invocation has been made, it is possible to poll for the reply in a client different from the one that made the initial request. An application takes advantage of this by passing the Poller from the client that made the request to the client that intends to poll for the reply (presumably by way of an Object 
instance that is collocated with the latter client). Since this Poller is implemented through the use of a PersistentRequest object implemented by the Messaging layer, that PersistentRequest must be accessible to whichever client uses that Poller. When the TII is used, it is possible for the polling client to obtain the reply after the original invoking client no longer exists. Since the PersistentRequest must be implemented in a server that is accessible to the Polling client, that PersistentRequest must be external to the original invoking client. A common design might be to have the PersistentRequest in this case be implemented by a corporate Router accessible to the invoking client as well as to the client that intends to poll for the response. The creation of PersistentRequest objects is discussed in detail in the Section 1.4, "Message Routing Interoperability", on page 1-44." 

to read 

"A client uses the Poller in a similar fashion as in the DII deferred synchronous model. The programmer can at any time choose to check whether or not the reply has arrived and deal with it in the current programming context. The user may also ask a Poller to block until the reply has arrived. The PersistentRequest reference is specified to allow client applications to save it in a persistent store and to enable interoperability between Messaging products. 

When a Time-Independent Invocation has been made, it is possible to poll for the reply in a client different from the one that made the initial request. An application takes advantage of this by passing the Poller from the client that made the request to the client that intends to poll for the reply (presumably by way of an Object 
instance that is collocated with the latter client or by instantiating an equivalent Poller in the latter client using the initializer). Since this Poller is implemented through the use of a PersistentRequest object implemented by the Messaging layer, that PersistentRequest must be accessible to whichever client uses that Poller. When 
the TII is used, it is possible for the polling client to obtain the reply after the original invoking client no longer exists. Since the PersistentRequest must be implemented in a server that is accessible to the Polling client, that PersistentRequest must be external to the original invoking client. A common design might be to have the 
PersistentRequest in this case be implemented by a corporate Router accessible to the invoking client as well as to the client that intends to poll for the response. The creation of PersistentRequest objects is discussed in detail in the Section 1.4, "Message Routing Interoperability," on page 1-44. 
  
  

b) -------------------------------------------------------------- 

The following changes are referring to document ptc/00-02-05. 

p. 1-24, 1-25 change 

"The Poller has the following definition: 

module Messaging { 
    valuetype Poller : CORBA::Pollable { 
        readonly attribute Object operation_target; 
        readonly attribute string operation_name; 
        attribute ReplyHandler associated_handler; 
        readonly attribute boolean is_from_poller; 

        Object target; 
        string op_name; 
    }; 
};" 

to read 

"The Poller has the following definition: 

module Messaging { 
    typedef string CorrelationId; 

    valuetype Poller : CORBA::Pollable { 
        readonly attribute Object operation_target; 
        readonly attribute string operation_name; 
        attribute ReplyHandler associated_handler; 
        readonly attribute boolean is_from_poller; 
        readonly attribute CorrelationId id; 

        Object target; 
        string op_name; 
    }; 
};" 

p. 1-25, add after the paragraph 'is_from_poller' 

"id 
A correlation id for the request is accessible from any poller. The returned string is of opaque content. Non-TII applications may only use it for comparison: the correlation id for two pollers are the same if and only if the 
pollers refer to the same original request. 

When Time-Independent Invocations are made, the reply may be obtained by a different client than the one that made the original request. An instance of a special poller subtype is returned from such invocations. The instance contains the state necessary to allow polling to be performed in a client distinct from the one that made the request. This state is used privately by the messaging-aware ORB and is not directly accessible to the application. However, the correlation id attribute provides the applications access to this state in 
a stringified form. This allows the state to be stored in a persistent store and later use it for initializing an equivalent poller in the client that will poll the reply." 
  
  

p. 1-18, change 

"1.3.6.2 Persistent Type-Specific Poller 
When Time-Independent Invocations are made, the reply may be obtained by a different client than the one that made the original request. An instance of persistent poller is returned from such invocations. The PersistentPoller contains the state necessary to allow polling to be performed in a client distinct from the one 
that made the request. This state is used privately by the messaging-aware ORB and is not directly accessible to the application. 

The generated PersistentPoller value is derived from the basic one. It adds no methods, only one piece of private state. For an interface named ifaceName the following PersistentPoller is generated: 

    value AMI_<ifaceName>PersistentPoller : AMI_<ifaceName>Poller { 
        MessageRouting::PersistentRequest outstanding_request; 
    }; 

Just as with any CORBA value this PersistentPoller can be passed as an argument to IDL operations and a copy of the Poller will be instantiated local to the callee." 

to read 

"1.3.6.2 Persistent Type-Specific Poller 
When Time-Independent Invocations are made, the reply may be obtained by a different client than the one that made the original request. An instance of persistent poller is returned from such invocations. The PersistentPoller contains the state necessary to allow polling to be performed in a client distinct from the one that made the request. This state is used privately by the messaging-aware ORB and is not directly accessible to the application. 

The generated PersistentPoller value is derived from the basic one. It adds no methods, only one piece of private state and an initialier. For an interface named ifaceName the following PersistentPoller is generated: 

    valuetype AMI_<ifaceName>PersistentPoller : AMI_<ifaceName>Poller { 
        private MessageRouting::PersistentRequest outstanding_request; 

        factory init(in Messaging::CorrelationId id); 
    }; 

This PersistentPoller can be instantiated by the application by providing the value of the correlation id attribute of the persistent poller returned from a Time-Independent Invocation. For optimisation reasons, it is not required that PersistentPoller instances that are created via the initializer will have the target and op_name members initalized with the values from the original request upon creation. 

This PersistentPoller can also be passed as an argument to IDL operations and a copy of the Poller will be instantiated local to the callee. Note that the IDL operation must use the generic Poller or Pollable type for the parameter because type-specific pollers are only defined in implied-IDL." 
  

p. 1-67, change 

" 
// 
// Base value for the Polling model 
// 
valuetype Poller : CORBA::Pollable { 
    readonly attribute Object operation_target; 
    readonly attribute string operation_name; 
    attribute ReplyHandler associated_handler; 
    readonly attribute boolean is_from_poller; 

    Object target; 
    string op_name; 
}; 
" 

to read 

" 
// 
// Base value for the Polling model 
// 
typedef string CorrelationId; 

valuetype Poller : CORBA::Pollable { 
    readonly attribute Object operation_target; 
    readonly attribute string operation_name; 
    attribute ReplyHandler associated_handler; 
    readonly attribute boolean is_from_poller; 
    readonly attribute CorrelationId id; 

    Object target; 
    string op_name; 
}; 
" 
  

p. 1-99, change 

"A client uses the Poller in a similar fashion as in the DII deferred synchronous model. The programmer can at any time choose to check whether or not the reply has arrived and deal with it in the current programming context. The user may also ask a Poller to block until the reply has arrived. The PersistentRequest reference is not visible to the client application, but is specified to enable interoperability between Messaging products. 

When a Time-Independent Invocation has been made, it is possible to poll for the reply in a client different from the one that made the initial request. An application takes advantage of this by passing the Poller from the client that made the request to the client that intends to poll for the reply (presumably by way of an Object 
instance that is collocated with the latter client). Since this Poller is implemented through the use of 
a PersistentRequest object implemented by the Messaging layer, that PersistentRequest must be accessible to whichever client uses that Poller. When the TII is used, it is possible for the polling client to obtain the reply after the originalinvoking client no longer exists. Since the PersistentRequest must be implemented in a server that is accessible to the Polling client, that PersistentRequest must be external to the original invoking client. A common design might be to have the PersistentRequest in this case be implemented by a corporate Router accessible to the invoking client as well as to the client that intends to poll for the response. The creation of PersistentRequest objects is discussed in detail in the Section 1.4, 
"Message Routing Interoperability", on page 1-44." 

to read 

"A client uses the Poller in a similar fashion as in the DII deferred synchronous model. The programmer can at any time choose to check whether or not the reply has arrived and deal with it in the current programming context. The user may also ask a Poller to block until the reply has arrived. The PersistentRequest reference is not visible to the client application, but is specified to enable interoperability between Messaging products. 

When a Time-Independent Invocation has been made, it is possible to poll for the reply in a client different from the one that made the initial request. An application takes advantage of this by passing the Poller from the client that made the request to the client that intends to poll for the reply (presumably by way of an Object 
instance that is collocated with the latter client or by instantiating an equivalent Poller in the latter client using the initializer). Since this Poller is implemented through the use of a PersistentRequest object implemented by the Messaging layer, that PersistentRequest must be accessible to whichever client uses that Poller. When the TII is used, it is possible for the polling client to obtain the reply after the original invoking client no longer exists. Since the PersistentRequest must be implemented in a server that is accessible to the Polling client, that PersistentRequest must be external to the original invoking client. A common design might be to have the 
PersistentRequest in this case be implemented by a corporate Router accessible to the invoking client as well as to the client that intends to poll for the response. The creation of PersistentRequest objects is discussed in detail in the Section 1.4, "Message Routing Interoperability", on page 1-44."

The rules for generating methods on callback interfaces can result in name clashes if the original interface has methods named "xxx" and "xxx_excep". I'd suggest avoiding this problem by appending a well-known suffix to both regular and exceptional callback operations (e.g. regular responses are handled by "xxx_complete", and exceptional responses are handled by "xxx_excep")

Exceptions are sent as type-specific valuetypes to callback objects. This prevents callback objects from being implemented using the DSI for several reasons. 1. Given the information available to the callback (the interface RepositoryID and method name), there is no way to determine the RepositoryID or TypeCode of the type-specific exception holder. This prevents the callback from correctly establishing the NVList passed to ServerRequest::arguments(). 2. The ORB in which the callback is implemented must contain a value factory capable of instantiating the correct type-specific valuetype. This requires that the application know which exception holder valuetypes are expected ahead of time, so that it can register factories appropriately. It may also require that the application be linked with the generated code for the type-specific exception holder. 3. There is no generic way to retrieve the exception from the exception holder -- you can only raise the exception by calling a type-specific method on the type-specific valuetype instance. This requires that the callback be programmed and linked against the type-specific exception holder.

Summary: I would like to raise the following issues with Messaging. Both refer to 6.6.4 
 is_from_poller:
 
 1. The following statement is open for interpretation:
 "The is_from_poller attribute returns the value TRUE if and only if the poller 
 operation itself raised a system exception."
 
 Does it refer only to the type-specific poll operation or to any operation on 
 the poller that can raise an exception? For example, a call to is_ready returns 
 a system exception. What is returned by a subsequent invocation of 
 is_from_poller?
 

Summary: 2. If the above quoted statement is correct, the following statement must be 
 wrong:
 "If the Poller has not yet returned a response to the client, the BAD_INV_ORDER 
 system exception is raised."
 If the poller operation itself raises a system exception, the poller has not 
 yet returned a response to the client, but should return TRUE according to 
 quoted statement under 1.
 
 I think that the intended behavior is be that the system exception 
 BAD_INV_ORDER is raised, if is_from_poller is not called in a context where the 
 previous call (only type-specific poll or any? -> see issue 1) to the poller 
 has returned an exception.
 

This message includes a short summary and a list of changes in
the spec. document.

It has been pointed out that type specific exception holder offers
little use and introduces many problems and complicities. Some of 
these problems have been discussed by Matthew Mihic in issue 2628 
and his recent message on DSI callbacks. To preserv type specific
exception holder and fix its problems would need more changes beyond 
the scope of messaging specification itself and would make things
more complicate. Therefore, we suggest to simply remove it.

It has been pointed out that type specific exception holder offers 
little use and introduces many problems and complexities. Some of 
these problems have been discussed by Matthew Mihic in issue 2628 
and his message on DSI callbacks in the archive for Issue 2929. 
To preserve type specific exception holder and fix its problems 
would need more changes beyond the scope of messaging specification 
itself and would make things more complicated . 

Therefore Ke Jin of Inprise proposed a solution a while back, which has 
now been revised to point out the editing revisions against the latest Messaging 
Chapter, which suggests simply removing it. 

The Summary of the main points of the proposal: 

1. Remove type specific exception holders from the current Messaging 
   specification and use an extended generic exception holder where 
   a type specific one was used. 

   Rational: 

   One of the main intentions of type specific holders is to have an 
   exception list at interface granularity (if the list is kept 
   by the exception holder) or method granularity (if separate 
   lists are kept for each raise_xxx() methods of the exception 
   holder) instead of a global exception list. To achieve the same 
   function without using type specific exception holders, we suggest, 
   an ORB can keep a user exception list(interface level) or lists 
   (method level) in the reply handler itself. The generic exception 
   holder's local (i.e. in reply handler's local ORB) implementation 
   can have an internal user exception list data member which will 
   be set to refer to one of above given lists (by language mapping 
   code) before the skeleton making an upcall of xxx_excep() method 
   which passes this generic exception holder as parameter. 

2. Extend the generic exception holder by adding raise_exception() 
   and raise_exception_with_list() methods. The raise_exception() 
   replaces the raise_xxx() in those old type specific holders. The 
   raise_exception_with_list(), largely from Matthew Mihic's 
   suggestion, is used by a DSI reply handler server to raise 
   exception using an application provided exception list. 

   Rationale: 

   The IDL mapping of raise_exception() and raise_exception_with_list() 
   methods should allow any CORBA exceptions (i.e. system or user) be 
   raised from this method. The raises clause of these method should 
   not to be limited to a specific set of IDL exceptions. As such, it 
   is defined as: 

     module Messaging { 
        ... 

        native UserExceptionBase; 
        valuetype ExceptionHolder { 
            void raise_exception() 
                 raises (UserExceptionBase); 
            void raise_exception_with_list( 
                 in CORBA::ExceptionList exc_list) 
                 raises (UserExceptionBase); 
           ... 
        }; 
     }; 

   Language mappings should choose suitable native 
   UserExceptionBase type (E.g. map to CORBA::UserException 
   in C++ and to org.omg.CORBA.UserException in java). As usual, 
   CORBA::SytemException (or omg.org.CORBA.SystemException) 
   doesn't need to be in the clause for raising it from the 
   method. 

Above changes not only solve issue 2628 and eleminate issues 
2524, 2658 but also largely simplify the Messaging spec.. 

Hi,
    I do not know how to direct the following issues, but we feel that
these merit concern and some re-examination in the Async specification -
Please could these be conveyed to the appropriate people, as I do not
know where to send these: Here are our concerns:

-       only supports righteous object as reply handler.  Therefore it
doesn't
adequately support our needs on platforms like resource constrained
environments,
where each application may be single-threaded.  It's klunky for this
because the app has
to be a server as well as a client in order to be nice to the user while

waiting for the reply.  Also, the server must be aware that the request
was
issued asynchronously.

The topic of whether callbacks should be righteous objects was debated hotly in the original submission. A change such as this is out of scope of an RTF. This was discussed at the last 2 Messaging RTF face to face meetings and everybody agreed. 
Close this issue. 

       There is a somwhat awkward way of unmarshaling exceptions.  The
client must
open a try block, call a raise method, and catch the unmarshaled
exception.
 This seems unnecessary.  There's no reason the exception can't be
unmarshaled in
the normal way.  Consequently in order to support the current model
value types are
unnecessarily required.

This was discussed for a long long time in a face to face meeting about 6 months ago. What is the "normal" way of raising an exception in a language neutral way when you are not in fact calling an operation but it is being called on you. 
The only other possibility that was proposed was that the exception could be embedded within an any, which seems 
to be possible now, but this was thought to be equally clunky, and probably undesirable since many uses of AMI are likely to be in minimum footprint environments where it is desirable to have the possibility to leave out "any" if it is not used. 
Close this issue, unless somebody comes up with a proposal that works. 

  The asynchronous methods for a given interface are all grouped
together
in one reply handler class.  This is an arbitrary grouping that forces
the
ORB to do some demutiplexing and potentially forces the user to deal
with
methods that he/she never intends to call, to say nothing of the fact
that the
handler class's virtual table becomes huge in C++.

What is the alternative? Generate a reply handler interface per method? This would really make a lot of 
generated code. The user can easily throw NO_IMPLEMENT or some such thing in callback operations 
that they know will never have called. The problem with virtual tables is probably not in the handler 
actually, but in the main stub class. The handler has 2 methods for every method in IDL(op, op_excep), whereas the 
stub class has 3 (original, sendc, sendp). 
I dont see a good solution to this, which is probably why it was done this way. 
Close this issue. 

1. The operations CORBA::PollableSet::poll and CORBA::Poller::is_ready both 
have the same semantics: verify if a reply message is available and can be 
retrieved. The first one works on a set of pollers, the second one on a single 
poller.

  -> The naming of these operations should therefore be consistent.
  -> possible correction: define (additionally) a
     CORBA::PollableSet::is_ready Operation. Mark the existing one
     as obsolete.

he following changes are referring to document ptc/00-02-05. 

p. 1-41, change 

"In this example, after the PollableSet::poll indicates that a particular Poller has finished, the code makes the call on the type-specific poller in a non-blocking manner and doesn't bother checking for completion in the return value. Checking isn't necessary when only a single client is using the Poller, but it is the safe practice if multiple clients are waiting." 

to read 

"In this example, after the PollableSet::get_ready_pollable indicates that a  particular Poller has finished, the code makes the call on the type-specific  poller in a non-blocking manner and doesn't bother checking for completion in  the return value. Checking isn't necessary when only a single client is using the Poller, but it is the safe  practice if multiple clients are waiting." 

p. 1-42, change 

while (poll_set->number_left() > 0) { 
    // wait for a completion 
    CORBA::Pollable_ptr pollable = poll_set->poll(max_timeout); 
    // the returned Pollable is ready to return its reply 
  

to read 

while (poll_set->number_left() > 0) { 
    // wait for a completion 
    CORBA::Pollable_ptr pollable = poll_set->get_ready_pollable(max_timeout); 
    // the returned Pollable is ready to return its reply 
  

p. 1-99, speaks about PollableSet, but no change needed 
  

The following changes are referring to document ptc/99-12-07 

p. 7-13 - 7-14, change 

interface PollableSet { 

    exception NoPossiblePollable { }; 
    exception UnknownPollable { }; 

    DIIPollable create_dii_pollable(); 

    void add_pollable( 
        in Pollable potential 
    ); 

    Pollable poll( 
        in unsigned long timeout 
    ) raises( NoPossiblePollable ); 

    void remove( 
        in Pollable potential 
    ) raises( UnknownPollable ); 

    unsigned short number_left( ); 
}; 

to read 

interface PollableSet { 

    exception NoPossiblePollable { }; 
    exception UnknownPollable { }; 

    DIIPollable create_dii_pollable(); 

    void add_pollable( 
        in Pollable potential 
    ); 

    Pollable get_ready_pollable( 
        in unsigned long timeout 
    ) raises( NoPossiblePollable ); 

    void remove( 
        in Pollable potential 
    ) raises( UnknownPollable ); 

    unsigned short number_left( ); 
}; 

p. 7-15, change 

"7.4.3 interface PollableSet 

The pollable set contains potential happenings for which a poll can be  performed. The client adds potential happenings to the set and later polls the set to see if  any have 
occurred. PollableSet is a locality constrained object." 

to read 

"7.4.3 interface PollableSet 

The pollable set contains potential happenings for which a poll can be performed. The client adds potential happenings to the set and later queries the set to see if any have occurred. PollableSet is a locality constrained object." 

p. 7-15 - 7-16, change 

"7.4.3.3 poll 

    Pollable poll( 
        in unsigned long timeout 
    ) raises( NoPossiblePollable ); 

The poll operation asks the PollableSet if any of its potential happenings have occurred. The timeout parameter indicates for how many milliseconds this call should wait until the response becomes available. If this timeout expires before a reply is available, the operation raises the standard system exception CORBA::TIMEOUT. 
Any delegated invocations used by the implementation of this polling operation are subject to the single timeout parameter, which supersedes any ORB or thread-level timeout quality of service. Two specific values are of interest: 
* 0 - the call is a non-blocking poll which raises the standard system exception CORBA::NO_RESPONSE if the reply is not immediately available 
* 232-1 - the maximum value for unsigned long indicates no timeout should be used. The poll will not return until the reply is available. 

If the PollableSet contains no potential happenings, the NoPossiblePollable exception is raised. If an actual happening is returned, the PollableSet removes that happening from the set. For the typed Poller, removing the happening is necessary since its usefulness ends once the Poller completes. In the case of a DII happening, 
there may still be deferred requests outstanding; if this is the case, the client application must add the DIIPollable again to the PollableSet. 

When the poll operation blocks, the ORB has control of the thread and can process 
any work it has (such as receiving and dispatching requests through its Object 
Adapter). The poll operation can be used in an "event-style main loop" using 
ORB::work_pending and ORB::perform_work. 

If the ORB supports multiple threads, one thread may be blocking on a PollableSet while another is adding and removing potential happenings from the set. It is valid for the PollableSet to change dynamically while a poll is in progress. If another thread?s PollableSet::remove operation leaves the PollableSet empty, any blocked threads raise the NoPossiblePollable exception." 

to read 

"7.4.3.3 poll 

    Pollable get_ready_pollable( 
        in unsigned long timeout 
    ) raises( NoPossiblePollable ); 

The get_ready_pollable operation asks the PollableSet if any of its potential happenings have occurred. The timeout parameter indicates for how many milliseconds this call should wait until the response becomes available. If this timeout expires before a reply is available, the operation raises the standard system exception CORBA::TIMEOUT. Any delegated invocations used by the implementation of this polling operation are 
subject to the single timeout parameter, which supersedes any ORB or thread-level timeout quality of service. Two specific values are of interest: 
* 0 - the call is a non-blocking query which raises the standard system exception CORBA::NO_RESPONSE if the reply is not immediately available 
* 232-1 - the maximum value for unsigned long indicates no timeout should be used. The query will not return until the reply is available. 

If the PollableSet contains no potential happenings, the NoPossiblePollable exception is raised. If an actual happening is returned, the PollableSet removes that happening from the set. For the typed Poller, removing the happening is necessary since its usefulness ends once the Poller completes. In the case of a DII happening, 
there may still be deferred requests outstanding; if this is the case, the client application must add the DIIPollable again to the PollableSet. 

When the get_ready_pollable operation blocks, the ORB has control of the thread and can process any work it has (such as receiving and dispatching requests through its Object Adapter). The get_ready_pollable operation can be used in an "event-style main loop" using ORB::work_pending and ORB::perform_work. 

If the ORB supports multiple threads, one thread may be blocking on a PollableSet while another is adding and removing potential happenings from the set. It is valid for the PollableSet to change dynamically while a query is in progress. If another thread?s PollableSet::remove operation leaves the PollableSet empty, any blocked threads raise the NoPossiblePollable exception." 
  

p. 7-16, change 

"7.4.3.5 number_left 

    unsigned short number_left( ); 

The number_left operation returns the number of potential happenings in the  pollable set. A returned value of zero means that there are no potential happenings in the set, in which case a poll on the set would raise the NoPossibleHappening exception." 

to read 

"7.4.3.5 number_left 

    unsigned short number_left( ); 

The number_left operation returns the number of potential happenings in the pollable set. A returned value of zero means that there are no potential happenings in the set, in which case a query on the set would raise the NoPossibleHappening exception. 

2. In the polling model, the return value in a reply is not returned as return 
value. The reason for this could be that the CORBA Messaging Spec in the draft 
stage (orbos/98-03-11) once defined that all poll-operations return a boolean 
value. Later on this idea was abandoned, but no one thought to return return 
arguments as return arguments.

  -> Returning return arguments as out arguments is not consistent consistent.
  -> possible correction: define an (additional) polling-signature which returns
     return arguments as return arguments. Declare the existing one as 
obsolete. 

I think this probably is a good idea to change this. Right now it has symmetry ( a little) with the callback 
model, but this symmetry doesnt help much.... 

Section 1.3.6.1 Basic Type Specific Poller 

Change first bullet to read 

"The type returned by the operation declared in IDL, followed by" 

Strike the first subbullet of the fourth bullet concerning out parameters. 

Change the example code to reflect this. 

The name conflict resolution algorithm for implied-IDL operations and 
attributes (based on inserting "_ami" strings) does not cover all possible name 
conflicts.

Example: 
// IDL
interface A { void op (); };
interface B { void sendp_op() };

The implied-IDL operation A::sendp_op conflicts with B::sendp_op. 

-> Thus, according to the CORBA Messaging Spec a legal IDL can lead to an 
illegal implied-IDL. 

A possible correction could be to
- map operations and attributes to implied-IDL operations and attributes 
starting with '_sendc_', '_sendp_', etc.
- define the language mapping for implied-IDL names starting with '_'

This would also allow to get rid of the "ami_" string insertions.

First of all, it is not clear at all how A::sendp_op clashes with B::sendp_op. Clearly 
the fully qualified names are different. 

According to the first paragraph of section 22.6.1 the name munging rule for sendc  is: 

"The interface’s operations and attributes are mapped to 
implied-IDL operations with names prefixed by “sendc_”. If this implied-IDL 
operation name conflicts with existing operations on the interface or any of the 
interface’s base interfaces, “ami_” strings are inserted between “sendc_” and the 
original operation name until the implied-IDL operation name is unique." 

and similarly in section 22.6.2 the name munging rule for sendp is: 

"The interface’s operations and attributes are mapped to 
implied-IDL operations with names prefixed by sendp_. If this implied-IDL 
operation name conflicts with existing operations on the interface or any of the 
interface’s base interfaces, ami_ strings are inserted between sendp_ and the original 
operation name until the implied-IDL operation name is unique." 

Since both these rules say that you keep inserting "ami_" until you get an unique name, 
given that any interfcace has a finite number of methods with names that are already known 
when the munged names are computed, it is not clear under what circumstances one would 
get invalid IDL. 

  The semantics of unchecked narrow are defined more constrained than actually 
needed.

The specification states that the _unchecked_narrow operation always returns a 
valid object reference. I think this should be loosened such that it is 
permitted that a nil object reference is returned even if the parameter to 
_unchecked_narrow is not the nil object reference.

Since the proposed resolution to this issue failed in the last RTF, it is pretty clear people dont want to do this. Therefore this issue should be closed. 

I would like to raise the following issue with Messaging:

The specification of pollable sets is broken because there is no direct way to 
widen a poller to a pollable and to narrow a pollable to a poller.


Goal of pollable sets:
A client holds pollers to outstanding replies. He registers these pollers in a 
pollable set. The set can be queried if one of the pollers is ready, ie. if a 
corresponding reply can be retrieved by means of this poller. The client uses 
the ready poller to retrieve the available reply.


The problem:
Poller is a valuetype, Pollable an interface type. In general, valuetypes are 
not object references nor CORBA objects. This is true even if a valuetype 
supports an interface.
-> (a) How is it possible to obtain a pollable object reference from a poller 
instance?
-> (b) How is it possible to obtain a poller instance from a pollable object 
reference?


Why has Pollable be defined as an interface type in the first place?

I think the original Messaging spec designers were not aware of the fundamental 
difference between valuetypes and object references. Probably, the original 
design intention just was that every poller "is a" pollable. They probably 
thought if the poller supported the interface Pollable, each poller instance 
could be widened to a pollable and then narrowed back again to a poller.

Thus, a possible correction would be to define Pollable as an abstract 
valuetype instead of an interface.

Pollable is now an abstract valuetype, so this is fixed. 
Close this issue. 

Consider the following illustration:

You would like to write some code C++ that does various calls that could raise 
CORBA exceptions. Among the calls is a type-specific poll. Benefitting from C++ 
exceptions you would like to handle the possible exceptions at the end. 
Therefore, if the exception could be from the poller, you would like to find 
out whether the exception is from an exception reply that was raised by the 
poller or from an error in receiving the reply.

The proposed resolution allows to write code in the following style 

try 
{ 
    // do some calls which could raise CORBA exceptions 

    poller->typeSpecificPoll(timeout, ami_return_val, output_arg); 
} 
catch(CORBA::NO_RESPONSE & e) 
{ 
   if (poller->is_from_poller()) 
   { 
       cout << "no response -> reply has not yet arrived"; 
   } 
   else 
   { 
       cerr << e; 
       throw; 
   } 
} 
catch(CORBA::TIMEOUT & e) 
{ 
   if (poller->is_from_poller()) 
   { 
       cout << "timeout is up -> reply has not yet arrived"; 
   } 
   else 
   { 
       cerr << e; 
       throw; 
   } 
} 
catch(CORBA::Exception & e) 
{ 
    cerr << e; 
    throw; 
} 
  

Without this resolution, three times nested exception handling is required to 
get the same effect: 

CORBA::Boolean isFromPoller = false; 
try 
{ 
   // do some calls which could raise CORBA exceptions 

   try 
   { 
       poller->typeSpecificPoll(timout, ami_return_val, output_arg); 
   } 
   catch(...) 
   { 
       try   // note: three times nested! 
       { 
           isFromPoller = poller->is_from_poller(); 
       } 
       catch(...) 
       {} 
       throw; 
   } 
} 
catch(CORBA::NO_RESPONSE & e) 
{ 
   if (isFromPoller) 
   { 
       cout << "no response -> reply has not yet arrived"; 
   } 
   else 
   { 
       cerr << e; 
       throw; 
   } 
} 
catch(CORBA::TIMEOUT & e) 
{ 
   if (isFromPoller) 
   { 
       cout << "timeout is up -> reply has not yet arrived"; 
   } 
   else 
   { 
       cerr << e; 
       throw; 
   } 
} 
catch(CORBA::Exception & e) 
{ 
    cerr << e; 
    throw; 
} 

I doubt that it was the intent of the original spec to impose this on the 
applications. 

Proposed Resolution 

In document ptc/00-02-05: Draft Revised CORBA Messaging chapter, p. 1-25, 
change 

is_from_poller 
As described below, the type-specific pollers are queried to obtain the reply from an asynchronously invoked operation. If the reply is a system exception, it may be important for the client application to distinguish between an exception raised by the poll itself and an exception that is actually the reply for the asynchronous 
invocation. The is_from_poller attribute returns the value TRUE if and only if the poller itself has raised a system exception during the invocation of one of the type specific poller operations. If the exception raised from one of the type specific poller operations is the reply for the asynchronous operation, the value FALSE is returned. If the Poller has not yet returned a response to the client, the BAD_INV_ORDER system exception is raised." 

to read 

is_from_poller 
As described below, the type-specific pollers are queried to obtain the reply from an asynchronously invoked operation. If the reply is a system exception, it may be important for the client application to distinguish between an exception raised by the poll itself and an exception that is actually the reply for the asynchronous 
invocation.The is_from_poller attribute returns the value TRUE if and only if the poller itself has raised a system exception during the invocation of one of the type specific poller operations. If the exception raised from one of the type specific poller operations is the reply for the asynchronous operation or the Poller has not yet returned a reply, the valueFALSE is returned. If the Poller has The is_from_poller attribute must not 
raise any system exception. This is to prevent the requirement for nested exception handling." 

Given the possible misconception of the relationship between valuetypes and 
interfaces at the time the messaging spec was submitted, I would like to 
question the definition of PollableSet as a local interface 
(locality-constrained objects).

The purpose of PollableSet is to provide a container of pollers.

Fundamentally, the container could
(a) potentially be remote, or
(b) always be local

In case (a) it could be defined by a non-local interface, in case (b) by a 
valuetype. However, it is currently defined as a local interface. For what 
reason? Is it for that PollableSet references cannot be passed around (i), or 
for that PollableSet invocations are local to the process (ii)? Note that if 
(i) is not a requirement, then PollableSet could be defined as a valuetype for 
the same reason that poller was defined as a valuetype.

[Extract from a disussion about pollers as value, 
http://www.omg.org/archives/messaging/msg00041.html :
The Poller consists of two components:

(a) typed stubs through which operation results can be 
obtained by a client application
(b) persistent state allowing the implementation of these
operations to query the Messaging internals to obtain
the reply to a previous request.

This looks to me like exactly what you would encapsulate
in a Value.  Prior to OVB, you would have to specify
such an object in PIDL as a pseudo-object (such as the
current CORBA::Request for DII).  OBV gives us
the ability to no longer require such pseudo-IDL when
specifying these "objects with state".
]

Why not define PollableSet as a valuetype? This would have the advantage that a 
PollableSet can be passed as an argument to an operation.

What's so much different between a PollableSet and an array of pollers, such 
that PollableSet must be locality-constrained?

Basically, I see 2 possible resolutions: 
(a) leave PollableSet locality-constrained 
(b) change (local) interface PollableSet to a valuetype 

The idea of (b) would be that a pollable set could be passed to another polling 
client just as pollers. However, for interoperability reasons, this would 
require that the PollableSet valuetype also defines the state members. This 
wouldn't be difficult, however, there is no need for this, as the application 
can already do this by defining a sequence of pollers. But most important, it 
is unlikely that an application wants to pass around pollable sets at all 
because pollable sets are usually only created by the polling client that is 
going to receive the replies. 

Therefore I think it makes most sense to leave PollableSet locality-constrained 
as defined by the original submitters. 
Proposed Resolution: 
Close this issue 

In the following section, three policy names are used:
RelativeRoundtripTimeoutPolicy, RelativeTimeoutPolicy, and
RelativeReplyTimeoutPolicy.   I believe they all refer to the interface we
are defining in this paragraph--RelativeRoundtripTimeoutPolicy.  If not, we
have Policies that are not defined and a big big problem :)
 
Can we please clean this up by and editorial revision?
 
5.3.4.6 interface RelativeRoundtripTimeoutPolicy
This interface is a local object derived from CORBA::Policy. It is used to
indicate the
relative amount of time for which a Request or its corresponding Reply may
be
delivered. After this amount of time the Request is cancelled (if a response
has not yet
been received from the target) or the Reply is discarded (if the Request had
already
been delivered and a Reply returned from the target). This policy is applied
to both
synchronous and asynchronous invocations. When instances of
RelativeTimeoutPolicy are created, a value of type TimeBase::TimeT is passed
to
CORBA::ORB::create_policy. This policy is only applicable as a client-side
override. When an instance of RelativeReplyTimeoutPolicy is propagated
within a
PolicyValue in an INVOCATION_POLICIES Service Context, the ptype has value
REPLY_END_TIME_POLICY_TYPE and the pvalue is a CDR encapsulation
containing the relative_expiry converted into a TimeBase::UtcT end time (as
in the
case of ReplyEndTimePolicy).

Messaging RTF 1.2 adopted a resolution that changes
Pollable from an interface to an abstract valuetype.
DIIPollable inherits from this, and so also needs
to be changed to be a valutype (probably an  abstract 
one).

Change definition of DIIPollable in Corba Core from 
interface DIIPollable : Pollable {}; 

to 

abstract valuetype DIIPollable : Pollable {}; 

Jishnu knows where to make the change in his drafts. 

The original CORBA Messaging spec (orbos/98-05-05) defined ORB-level and 
thread-level policy managers. How do they relate to the policy management 
framework as defined in CORBA 2.3?

The current messaging draft (ptc/00-02-05, chapter 1.2.1) refers to CORBA Core 
for the definition of the policy management framework. However CORBA 2.3, 
chapter 4.9.4 Policy Associated with the Execution Environment, only describes 
that ORB- and thread-associated policy management is defined on a per service 
base. However, the original messaging spec defined ORB- and thread-associated 
policy management as a general mechanism, not specific to a particular service, 
see quote below.

Should there be now Messaging-specific policy managers at the ORB- and 
thread-level or should the current CORBA 2.3 policy management framework be 
extended to define generic interfaces for ORB- and tread-level policy 
management?

CORBA 2.3 was indeed inconsistent with the Messaging specification 
since it predates integration of Messaging into the Core. The problem brought up in 
this issue has been fixed in 2.4 by the incorporation of the text quoted above in 
CORBA Core section 4.9.2. So this issue can be closed no change. 

Section 6.5 "Type Specific ReplyHandler Mapping" does not specify whether the AMI generated interfaces should mirror the inheritence tree of their source interfaces: Example: module A { interface one { void f(); }; interface two : one { void g(); }; }; In this scenario, should the implied AMI_twoHandler interface extend AMI_oneHandler, or should it just contain callbacks for all of the methods defined in 'two' including those inheritted from 'one'?

Can a client call PersistentRequest::get_reply multiple times on the same request and receive a valid reply each time? Or should the first call "clear out" the reply such that subsequent calls raise an exception?

Resolution: Section 22.14.2.9 clearly states that: "If a response is returned to the caller, 
the PersistentRequest is deactivated so that future invocations of get_reply raise the 
system exception OBJECT_NOT_EXIST." 

This is further reiterated in section 22.14.2.8 where it says: "This attribute cannot be 
checked if the response has already been delivered to some caller of get_reply, as the 
PersistentRequest object will have been deactivated at that time and the ORB will 
return the system exception OBJECT_NOT_EXIST on any subsequent invocation 
on that PersistentRequest." 

Seems like there is no ambiguity on this metter and therefore no further clarification is necessary. 

 In the Messaging Spec, it is not specified whether ExceptionHolders should mirror the inheritance tree of the interfaces that they support.

Per the chair of the now deefunct Messaging RTF Chris Smith "This issue 
has already been dealt with but it has come back with a new number due to OMG losing 
some issues." So propose close no change. 

A question as to the semantics of policy value propagation.

What does propagating a policy value actually mean in terms of the
precedence of policy overrides (i.e. default, overridden by ORB level,
overridden by thread level, overriden by object reference level)? For
example, say a REPLY_END_TIME_POLICY_TYPE policy value is propagated
with a request in the INVOCATION_POLICIES service context, and the
target makes an onward invocation after setting a policy override of
ReplyEndTimePolicy on the current thread with a different end-time -
what's the precedence here between the propagated and overridden policy
values?

The last paragraph of CORBA Core Section 4.8.4 says: 

In general the policy of a specific type that will be used in an invocation through a 
specific object reference using a specific thread of execution is determined first by 
determining if that policy type has been overridden in that object reference. if so then 
the overridden policy is used. if not then if the policy has been set in the thread of 
execution then that policy is used. If not then the policy associated with the capsule is 
used. For policies that matter, the ORB ensures that there is a default policy object of 
each type that matters associated with each capsule (ORB instance). Hence, in a 
correctly implemented ORB there is no case when a required type policy is not 
available to use with an operation invocation. 

This clearly states the precedence rule. So this issue can be closed no change.