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

Jira Issues

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

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,   https://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.   

formal/98-12-01 has native ::CORBA::Message  formal/00-04-01 has native ::CORBA::MessageInterceptor::Message  

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.