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 4012: Precedence of propagated policy values Jira Issue ZZMSG-43
Issue 1613: QoS Policy values in compliance chapter (messaging-rtf)
Click here for this issue's archive.
Nature: Revision
Severity:
Summary: Summary: The compliance chapter needs to clarify which (if any) QoS Policy values must be supported by a compliant implementation.
Resolution:
Revised Text: 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.
Actions taken:
June 30, 1998: received issue
January 9, 2001: closed issue
Discussion: 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.
Issue 1666: 6.8.3.1 C++ Example of Generated Poller (messaging-rtf)
Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary: 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.
Resolution:
Revised Text: ) 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
Actions taken:
July 13, 1998: received issue
January 9, 2001: closed issue
Discussion: 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
Issue 2263: reply handler object in the AMI model (messaging-rtf)
Click here for this issue's archive.
Nature: Clarification
Severity:
Summary: 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.
Resolution: close this issue
Revised Text:
Actions taken:
December 17, 1998: received issue
January 9, 2001: closed issue
Discussion: It is sufficiently clear that a reply handler can be outside the process whch issued the AMI request. Close this issue.
Issue 2352: Errant Messaging::Timeout (messaging-rtf)
Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary: 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.
Resolution: Delete definition of Timeout from the IDL in section 5.3 and the summary IDL in 10.3.
Revised Text:
Actions taken:
January 28, 1999: received issue
October 4, 2000: closed issue
Discussion:
Issue 2353: Issue: create_policy explanation (messaging-rtf)
Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary: Summary: Issue: The definition of ORB::create_policy has led to some confusion. Clarify how specifications can make use of this operation.
Resolution: Close the issue
Revised Text:
Actions taken:
January 28, 1999: received issue
October 3, 2001: closed issue
Discussion: 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
Issue 2356: Poller may only be used in ORB that created it (messaging-rtf)
Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary: 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.
Resolution: clarified
Revised Text:
Actions taken:
January 29, 1999: received issue
January 9, 2001: closed issue
Discussion: 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.
Issue 2500: The Messaging specification mentions QueuedDeliveryPolicy twice (messaging-rtf)
Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary: 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.
Resolution: see above
Revised Text: : All changes relative to document orbrev/01-03-01 1. Replace QueuedDeliveryPolicy by RoutingTypePolicy in the last para of section C.1 on page 22-85
Actions taken:
March 2, 1999: received issue
October 3, 2001: closed issue
Discussion: 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.
Issue 2506: wording changes in AMI section 3.3.2 (messaging-rtf)
Click here for this issue's archive.
Source: Object Management Group (Dr. Jon M. Siegel, siegel(at)omg.org)
Nature: Uncategorized Issue
Severity: Minor
Summary:
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.
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.