Issue 1139: constant decls broken
Issue 2299: No way to detect that ORB has outstanding deferred synchronous requests
Issue 2431: issue with ForwardRequest exception in POA
Issue 2629: Getting reply svc ctxts from PersistentRequests
Issue 2772: Potential deadlock with POA::deactivate_object()
Issue 2785: scheme name for IORs
Issue 3076: Implementing proper handling of CloseConnection
Issue 3097: Custom Value Marshaling Issue
Issue 3318: Sending codeset context more than once?
Issue 3322: Portable Interceptors: object_to_string, string_to_object
Issue 3355: Question about routing policies
Issue 3403: PI needs the ORB to be available in IDL
Issue 3429: ORBInitInfo needs the ORB
Issue 3459: DynValue & custom valuetypes ORB mediation for servant managers, references for servant managers?
Issue 3541: How correlate requests and replies when using pollable sets?
Issue 3599: Detail lacking in when request interceptors are called
Issue 3601: Portable Interceptors: 9.2.3 text describing `Arguments'
Issue 3609: Overriding POA policies
Issue 3615: Policy Management in Portable Interceptors
Issue 3672: Portable Interceptors / register_initial_reference()
Issue 3674: Polymorphic Valuetypes and the DII
Issue 3770: RoutingPolicy issue
Issue 3772: ORB accessor on POA?
Issue 3793: no way to register value factory from ORB initializer
Issue 3907: Issue: CSIv2 Identity Assertion
Issue 3914: Missing minor codes in Messaging Chapter
Issue 3947: Portable interceptors and invocation timeouts
Issue 3989: No portable way to turn IOR components into object-reference policies
Issue 4008: wchar endianness
Issue 4065: How does an ORB implement Object::get_policy for PI defined policies?
Issue 4137: Implications of any/valuetype marshalling
Issue 4156: Encodings of Sequences of Certificates are not standard.
Issue 4164: ORB::shutdown vs. ORB::destroy
Issue 4167: Stateful boolean causes all CSI mechanisms to operate the same way.
Issue 4169: Avoiding RSC/TSC copy on server side
Issue 4173: Clarify that each interception point executes in a distinct logical thread
Issue 4236: X/Open Codeset registry is obsolete needs to be replaced
Issue 4284: 21.8.1 register_initial_reference
Issue 4290: Problem with CSIv2 and GIOP LocateRequest
Issue 4321: Interpretation of defined ServiceConfigurationSyntax constants is incomplet
Issue 4324: Note on page 15-43, OBJECT_FORWARD_PERM
Issue 4334: Repository ID in nil references
Issue 4337: rep_id() operation on Object?
Issue 4506: TypeCodes for custom marshaled valuetypes
Issue 4536: CORBA components requires new GIOP version?
Issue 4554: Detecting Recursion in Other Interceptors
Issue 4585: CORBA 2.5 and Portable Interceptors mismerged
Issue 4650: Alignment for empty sequence?
Issue 4723: ORBs using BOMs for UTF-16 (closely related to issue 4008)
Issue 4724: GIOP 1.2 encoding of wstring
Issue 4725: Chapters 13.10.1.9, and 13.10.1.12 -- issue
Issue 4796: TypeCode indirections
Issue 4806: Issue with chunking
Issue 4820: Potential problem using BiDir GIOP and codeset conversion service context
Issue 4822: 11.3.2.1 Processing States (end of second paragraph and third paragraph
Issue 4823: conflict between CORBA specification and C++ mapping (_this method
Issue 4824: Wide string in reply before codeset was negotiated
Issue 4825: IPv6 in corbaloc URLs
Issue 4835: interaction of #pragma and typeid, typeprefix
Issue 4846: The whole negotiation thing should be removed, Unicode should be mandated
Issue 4850: Codeset negotiation requires clarification
Issue 4851: IDL inheritance issue
Issue 4852: discussion on the create_union_tc operation could use some clarifications
Issue 4870: definition of the TypeCode interface (4.11.1)
Issue 4899: GIOP version in replies
Issue 4945: IOR processing performance
Issue 4982: Inconsitent exception handling with find_POA & unknown_adapter Generic operations for subscribing/unsubscribing at publishing ports
Issue 5100: Valuetypes supporting forward declared interfaces
Issue 5105: reference_to_servant
Issue 5214: Proposal for extension to CosNaming
Issue 5231: New issue: ForwardRequest(<local object>) Replace deprecated anonymous type declarations?
Issue 5232: Replace deprecated anonymous type declarations?
Issue 5266: ForwardRequest is impossible to detect in clients
Issue 5270: Codeset negotiation and the CODESET_INCOMPATIBLE exception
Issue 5296: Avoiding Interceptors for colocated method requests
Issue 5322: DATA_CONVERSION minor code 2 not listed in Table 4-3
Issue 5327: pragma prefix syntax
Issue 5329: Minor codes in specified NO_IMPLEMENT exceptions incomplete/inconsistent
Issue 5333: OpaqueValue/add_arg never mapped to languages
Issue 5430: Serious backward compatibility issue in the PI
Issue 5439: processing TaggedComponents within an IOR
Issue 5448: BAD_INV_ORDER minor code 5 and 10 mean the same thing?
Issue 5449: Wrong minor code listed in POAManager::deactivate
Issue 5467: How does DynValue handle derived valuetypes?
Issue 5587: Inconsistent definition of semantics of RebindPolicy?
Issue 5592: Object::get_client_policy problem
Issue 5614: Sloppy text in CORBA 3.0, 4.3.8.1 get_policy
Issue 5619: Object::validate_connection()
Issue 5620: Who is responsible for generating the TIMEOUT exception
Issue 5621: messaging router issue
Issue 5622: Is a router allowed to pick any value in the range for a priority?
Issue 5623: determining TimeT or UtcT value
Issue 5624: Spec doesn't make clear what is valid mix of policies and what is invalid
Issue 5626: Messaging time based policy enforcement?
Issue 5641: SyncScope for oneway invocations
Issue 5642: Messaging: bad example code for type specific poller
Issue 5660: Errors in definition of Messaging poller types
Issue 5661: Messaging type-specific poller valuetypes should be abstract
Issue 5662: Messaging Routing Protocol is broken for GIOP 1.0 & 1.1 potential name clash with Messaging type-specific poller timeout argument
Issue 5663: potential name clash with Messaging type-specific poller timeout argument
Issue 5664: AMI vs abstract & local interfaces name disambiguation for AMI interface & poller names is confusing Messaging Poller generation is broken for interfaces with multiple inherite
Issue 5665: name disambiguation for AMI interface & poller names is confusing Messaging Poller generation is broken for interfaces with multiple inherite
Issue 5666: Messaging Poller generation is broken for interfaces with multiple inherite
Issue 5667: Bad example code in 22.11.4.3
Issue 5668: DII sendc reply delivery underspecified
Issue 5669: Oneway operations should not generate sendc_ and sendp_ variants
Issue 5672: Pollable in more than one PollableSet?
Issue 5673: Why does PollableSet::number_left() return unsigned short?
Issue 5674: Local types allowed as valuetype state?
Issue 5687: Derived component supported interface restriction (formal/2002-06-01)
Issue 5689: Exception handling in Interceptor initialization
Issue 5690: ORBInitInfo::arguments() underspecified
Issue 5691: What ORBInitInfo operations are legal during pre_init() and post_init()?
Issue 5692: What ORBInitInfo operations are legal during pre_init() and post_init()?
Issue 5726: How do Portable Interceptors interact with Messaging callbacks
Issue 5743: CORBA::WrongTransaction and Interceptors
Issue 5764: add a ClientInterceptor then create_POA() in the post_init() method?
Issue 5766: Unfortunate CDR Encapsulation of ASN.1 Encodings
Issue 5771: Type code creation
Issue 5781: What is the RSC when using a PersistentPoller
Issue 5856: Bad text in 22.6 mandates Routing for sendc/sendp
Issue 5880: Clarification on multi-threaded codeset negotiation
Issue 5892: restriction of where a valuetype chunk can end
Issue 5895: Problem with ServerRequestInterceptor::receive_request and DSI
Issue 5899: rules for marshalling ValueBoxes
Issue 5939: ValueMembersSeq
Issue 5941: valuetype fragmentation ambiguous
Issue 5952: BNF changes
Issue 6007: Mapping from -ORBxxx to Java properties does not work for -ORBInitRef
Issue 6050: 15.3.3 - codesets must be "explicitly defined"
Issue 6283: CodeSet and CSIv2 Negotitaion
Issue 6285: Change new GIOP Negotiate Session Message to Firewall Specific
Issue 6287: Chapter/section: 15.4.2.2 "Request Body"
Issue 6314: GIOP Conformance and Interceptors
Issue 6318: valuetypes and local interfaces
Issue 6391: Interface Introspection
Issue 6424: Section 22.2.4.6 interface RelativeRoundtripTimeoutPolicy
Issue 6899: CORBA 3.02, page 11-25, section 11.3.6
Issue 6912: Error in Chapter 21 of CORBA 3.0
Issue 7340: module SendingContext
Issue 7592: An extension of IOR to protect target objects Nature
Issue 7730: Codec Interface Deficiencies
Issue 7731: Codec Interface Deficiencies
Issue 7890: methods on the POA
Issue 7891: Make a typedef for the POA id new
Issue 7892: Add a typedef for the POAManager id
Issue 7893: change in the POAManager
Issue 7896: argument of the set_servant call has a small typo
Issue 7900: omission from the OMG --Trader spec
Issue 7955: The POA state inactive is not used consistent.
Issue 7978: CORBA 3.0.3 ch. 3.4 OMG IDL Grammar
Issue 8221: Section: 4.3.13
Issue 8230: Appendix A
Issue 8244: Code Set Conversion on Operations
Issue 8586: Moving *Seq typedefs into ORB chapter
Issue 8618: Minor code ambiguity
Issue 8629: Typo in sections 22.10.1.1 and 22.10.1.2
Issue 8630: Section: 7.4
Issue 8631: Section: 13.6.2
Issue 8632: Section: 4.2
Issue 8633: Section: 4.2 (02)
Issue 8783: update the spec to not used anonymous types
Issue 8843: Section: 21.7
Issue 8844: Section: 21.9.1
Issue 8856: Section: 21.4.3.1
Issue 8860: Section: 4.5.2
Issue 8862: Section: 21.3.14.11
Issue 8864: Section: Appendix A
Issue 8874: Page: 21-5
Issue 8879: Page: 9-1
Issue 8881: Page: 7-7
Issue 8929: NVList Section: 7.5
Issue 8969: Allowing Mutual Recursion for IDL Structures
Issue 8985: Section: Chapter 11
Issue 8986: Section: Chapter 9, Chapter 5
Issue 9016: Section: 11.3.9
Issue 9075: Section: 22.16/
Issue 9082: Section: 22.11.1
Issue 9112: Page: 21-43
Issue 9118: Page: 56..64
Issue 9140: FullInterfaceDescription and base_interfaces question
Issue 9460: Section: 11.3.9.16
Issue 9618: CORBA Exceptions
Issue 10558: Allowing mutual recursion for IDL structs - clarification needed
Issue 10817: Section: 21.3.13
Issue 11027: Section: exceptions
Issue 11161: Section: 13.6.10.1
Issue 11332: Section: 15.4.2/16.4.1
Issue 11514: Proposal to change PortableInterceptor::ReplyStatus to a real enum
Issue 11515: Proposal to change PortableInterceptor::AdapterState to a real enum
Issue 11525: Third line of 23.1.3.4, ACTIVE must be bold
Issue 12229: definition of Invalid Policies changed
Issue 12230: mention of (deprecated) function get_implementation removed from text
Issue 12376: Section: Part 2, Chapter 11 - MIOP
Issue 1139: constant decls broken (corba-rtf)
Click here for this issue's archive.
Source: IONA (Mr. Steve Vinoski, steve.vinoski@iona.com vinoski@iona.com)
Nature: Revision
Severity:
Summary:
Summary: When the extended IDL types were added to CORBA, the semantics of IDL constant declarations seems to have been broken. In CORBA 2.0 (July 1995) the third paragraph of section 3.7.2 page 3-18 states: "An integer constant expression is evaluated as unsigned long unless it contains a negated integer literal or the name of an integer constant with a negative value. In the latter case, the constant expression is evaluated as signed long. The computed value is coerced back to the target type in constant initializers. It is an error if the computed value exceeds the precision of the target type. It is an error if any intermediate value exceeds the range of the evaluated-as type (long or unsigned long)." The paragraph following the one quoted above explains the same for floating-point constants. Unfortunately, CORBA 2.2 has broken this. Section 3.7.2, page 3-20, of formal/98-02-01 tells us what to do if types are long, unsigned long, long long, unsigned long long, double, and long double, but the old text stating how general integer constants and floating point constants were evaluated has been completely removed! How should the following be evaluated? const short S = 1 + 2;
Resolution: 1. For integer types evaluate the expression using the imputed type of each argument of a binary operator in turn. So: a. If either argument is unsigned long long, use unsigned long long. b. If either argument is long long, use long long c. If either argument is unsigned long, use unsigned long. d. Otherwise use long. 2. Constant integer literals are considered long unless the value is too large, then they are long long. (Unary minus is considered an operator, not a part of an integer literal). 3. For floating point types evaluate the expression using the imputed type of each argument of a binary operator in turn. So: a. If either argument is long double, use long double. b. Otherwise, use double 4. Constant floating point literals are of the smallest type that holds the number of decimal digits that the literal was specified with (Unary minus is considered an operator, not a part of an integer literal). 5. Finally, we need a statement that the final result of an arithmetic expression must fit in the range of the declared type of the constant, otherwise it is an error. Truncation on the right for floating point or fixed point is ok.
Summary: Issue: There is currently no way to detect that an ORB has outstanding deferred synchronous requests. In the DII, this was possible via the blocking ORB::get_next_response operation. A mechanism is needed so that applications can (for example) shutdown gracefully only after all outstanding deferred synchronous operations have returned results.
Resolution: The ORB shutdown operation should wait for outstanding deferred synchronous "sendc" mode operations to have returned results before completing. If this is not done, sendc invocations invoked with a callback object on another ORB could be "terminated" prematurely during ORB::shutdown, and no response forwarded to the callback. One could claim that the paragraph cited from section 4.2.5.4 below says this already, but it is not clear. Clarification of the intent of the paragraph as suggested below fixes this problem
Summary: The ForwardRequest exception in the POA specification doesn"t allow the servant manager to specify whether the status of the GIOP reply is LOCATION_FORWARD or LOCATION_FORWARD_PERM. If an application is designed to use ForwardRequest exceptions, then it should be able to state whether the new object reference is transient or permanent.
Resolution: A quick read of the Fault Tolerance Chapter in 3.0, see: http://cgi.omg.org/docs/formal/02-06-59.pdf , I get the sense that a LOCATION_FORWARD_PERM never comes all the way upto a POA. So a ServantManager has no occasion to have to deal with it. Hence this issue can be closed no change
Summary: It does not appear that reply service contexts are maintained when retrieving polled requests from a Router. Although the Router interfaces properly propogate the service contexts to the the untyped reply handler representing the PersistentRequest, there is no way for the client to retrieve these contexts from the PersistentRequest::get_reply. This may make it impossible for the client to interpret the reply data (e.g. if the reply contained CodeSet contexts).
Resolution: This is indeed an outage. Add a new operation to PersistentRequest called get_reply_with_context, which is exactly like get_reply in every way except that it has an additional parameter for returning the service context associated with the reply. Since this is just an addition of an operation to an existing interface, there is no need to give a new RepId to it, as an attempt to invoke this operation on a legacy version of the interface is handled adequately by a system exception
The draft CORBA 2.3 spec (ptc/99-03-07) does not deal with a potential deadlock situation. If an object is explicitly deactivated with POA::deactivate_object(), the object remains in the active object map until all operations pending on the object have completed. Any attempts to reactivate the object (implicitly via a ServantActivator, or explicitly via activate_object_with_id()) must block until the pending invocations have completed. However, if a servant's implementation of an object deactivates the object and then (directly or indirectly through a call to another collocated object) reactivates the object, the invocation will deadlock.
Summary: The syntax for stringified IORs in section 13.6.6 shows: <prefix> = "IOR:" The problem is that URL scheme names are supposed to be case insensitive. So, "Ior:" or "ioR:" should be allowed to. I would suggest to add a footnote to state that case for the scheme name is ignored.
The CORBA 2.3 spec says in chapter 15.7.1: "After receiving a CloseConnection message, an ORB must close the TCP/IP connection. After sending a CloseConnection, an ORB may close the TCP/IP connection immediately, or may delay closing the connection until it receives an indication that the other side has closed the connection. For maximum interoperability with ORBs using TCP implementations which do not properly implement orderly shutdown, an ORB may wish to only shutdown the sending side of the connection, and then read any incoming data until it receives an indication that the other side has also shutdown, at which point the TCP connection can be closed completely." Most (or all?) Unix TCP/IP implementations suffer from the problem described above, i.e., with most Unix TCP/IP implementations the last message sent is discarded if the connection is closed. The workaround, to shut down the sending side only, and then to read data until EOF is received, works fine for C++ ORBs. However, there is no equivalent to shutdown() in Java, so I don't see any way to reliably transmit the CloseConnection message from a Java ORB running on Unix. Questions: - Is there perhaps some other way to reliably transmit the last message before closing the connection, using Java running on Unix? - If not, doesn't this mean that IIOP's connection closure strategy is unimplementable in Java under most Unixes?
Resolution: As per the issue filers later note, the particular mis-feature of JDK has been fixed in JDK 1.3. There does not appear to be a pressing reason to complicate the standard in order to deal with the corner cases which use TCP implementations which do not properly implement orderly shutdown. So close this issue no change.
Due to the way that custom values are marshaled it is nearly impossible for a bridge (or other process) to process/forward GIOP messages which contain custom marshaled values (which the bridge has no compile/run-time knowledge of). The main issue is that the "alignment" of the custom marshaled data is unknown, other than the data will always start on a four byte boundry due to the presence of chunking. Should/could the value encoding format be changed to enforce eight byte alignment for all custom marshaled data (chunks)? This would allow bridges and other tools to process->[store]->forward messages containing custom values.
Question: Is it legal to send the same codeset context more than once
on the same connection?
The spec says:
Codeset negotiation is not performed on a per-request basis,
but only when a client initially connects to a server.
These words suggest that the codeset must be sent on the first request,
but don't say whether it's OK to send it more than once.
I would like to have clarification, and also a loose interpretation. Here
is why:
A multithreaded client starts talking to a new object from
multiple threads more or less simultaneously. If the codeset
info must be sent only on the first request and is illegal on
subsequent requests, we end up with rather complex locking
logic in the connection management layer of the ORB. In effect,
each request is no longer a stand-alone and context-free thing;
instead, how to send a specific request now depends on what
other threads may have done in the past.
That's not very nice (even though it can be implemented) because
it needlessly complicates things.
So, I would like to change things such that it is legal to send the
codeset context even if it was sent previously on the same connection.
When that happens, the server should simply and silently ignore all
but the first context (even if the subsequent contexts have different
codeset information from earlier ones). That way, requests remain
context-free. [ Yet again, we see a sterling demonstration that attaching
semantics to the duration of a connection was a very bad idea, especially
in a model that is connectionless :-( ]
Further, it seems pointless to send codeset info at all unless the client
actually uses an operation that involves a wchar or wstring parameter.
So, I think it would make sense to relax things such that the codeset
need not be sent until the first request is made that requires sending it.
Resolution: After much email discussion there appears to be a consensus that has evolved that it is OK to send additional codeset service context, but if subsequent codeset service contexts on a link contain something different from the one contained in the first one then the behavior is undefined
object_to_string and string_to_object are missing on ORBInitInfo.
Resolution: Adding an ORB accessor to the Object interface as proposed in the resolution for Issue 3772 together with making that operation return the relevant ORB for local objects of relevance automatically provides access to these operations from ORBInitInfo. So resolve this issue in conjunction with the resoltuion for issue 3772.
How are the routing policies e.g.ImmediateSuspend, LimitedPing, UnlimitedPing, etc. created. It is not clear that these can be created using the standard create_policy operation since these policies are valuetypes that support the CORBA::Policy interface. Also what are the Policy Type tag values for these policies?
Resolution: The Policy Type tags have been fixed for this earlier. The fact that CORBA::Policy interfaces are supported by the policy valuetypes is probably because someday someone might want to integrate this into the general policy management architecture, and this by itself causes no harm. The fact there there are no factories specified for these is OK because the only place where these need to be created are within an ORB, and can hence be done using internal mechanisms and interfaces that need not be standardized. So close this issue no change
Portable interceptor implementations need access to the ORB. In order to accomplish this, the ORB must be defined in IDL There are four possibilities that have been opined: 1. Define the ORB as "native ORB;" This puts the ORB into the IDL namespace. However, the ORB is still described in PIDL. This doesn't really help us to remove PIDL, some folks feel this is a misuse of native, but it would be sufficient for the requirements of PI. 2. Define an IDL wrapper for the ORB, call it proxyORB for now. proxyORB would contain exactly the same items that the PIDL ORB does, only defined in pure IDL. Advantages: this is a migration step toward getting rid of ORB PIDL if we encourage folks to use proxyORB rather than ORB. Disadvantages: dual maintenance; lots of work - too much for this FTF?; I don't think we know all the ramifications; where do you get a proxyORB? from the ORB? 3. Make the leap and redefine ORB in IDL now. This option is similar to option 2, but the IDL is not a wrapper, it's the real ORB. Advantages: no dual maintenance; we get rid of ORB PIDL right now. Disadvantages: BIG step - too big for this FTF?; lots of work; I don't think we know all the ramifications. 4. Make the ORB a primitive type like TypeCode. This seems to be generally undesired. It requires all compilers to change. Unless someone really likes this approach, I don't think we should even consider it.
Resolution: Adding an accessor to the ORB in the Object interface together with having that accessor return the relevant ORB for relevant local objects provides the least obtrusive way of providing this facility. This is proposed as resolution for issue 3772. So this issue is simultaneously resolved with issue 3772. While the resolution for 3772 explicitly excludes Interceptor and its derived interfaces from the local interface in which get_ORB returns the ORB, any likely point where the Interceptor is available to call get_ORB(), an ORB provided local object (such as IORInfo, ClientRequestInfo, etc) is also available to call get_ORB() on.
Portable interceptor implementations need access to the ORB. The presumed place to put the ORB would be on ORBInitInfo since at least one implementation needs the ORB at initialization time. Is that sufficient? Or is it also needed in RequestInfo and IORInfo? My guess is that having ORB only on ORBInitInfo is sufficient. All interceptors begin here. If the ORB is needed at other points, the implementations can assure that it is available where it's needed. Since ORB is PIDL and we don't want to pollute the interceptor interfaces with PIDL, we have to create IDL access to the ORB, but that's another issue.
The CORBA 2.3.1 specification does not cover the interaction between the DynValue interface and custom valuetypes. I frankly don't see any way that the DynValue interface can possibly correctly handle a custom valuetype when the ORB does not have a factory for the type. It is theoretically possible for DynValue to properly work with a known custom type, but the implementation strategy could not be based on parsing the marshalled form of the valuetype. So, there are two issues that need to be addressed: 1. Should DynValue handle custom valuetypes at all? 2. For the set of custom valuetypes that it cannot handle, what exceptions should be raised by each operations?
When using the pollable sets, pollers are registered with
PollableSet::add_pollable() and retrieved using
PollableSet::get_ready_pollable(). As pollers are valuetypes they are passed by
copy, thus portable applications must assume that get_ready_pollable() returns
a different poller instance than the one passed to add_pollable(). Thus, with
non-TII, currently there is no portable way to find out how requests
(represented by the pollers returned from sendp) and replies (represented by
the pollers returned from get_ready_pollable ) correlate.
Consider the following IDL:
module Stock
{
interface Quoter { long get_quote(in string stock_name); }
};
and a client that does a 1000 invocations in the style
poller = quoter->sendp_get_quote(portfolio[i].stock_name);
poll_set->add_pollable(poller);
Now, the client could retrieve the 1000 replies in the order:
while(poll_set->number_left() > 0)
{
pollable = poll_set->get_ready_pollable(timeout);
...
};
But how can the client find out which returned quote belongs to which
stock_name?
Possible resolutions:
---------------------
(a) Reconsider the introduction of a correlation id on pollers which can be
used to compare if two pollers are referring to the same request/reply.
(b) Based on the fact that pollable set is locality-constrained and that
valuetypes support sharing semantics (see CORBA 2.3, 5.2.4.2 Sharing
Semantics), it could be required that PollableSet::get_ready_pollable() returns
a pointer to the same valuetype instance as the one passed as argument of
PollableSet::add_pollable().
(c) Close without action, i.e. has to be solved at the application level, e.g.
in our example the application would have to solve this by changing get_quote to
long get_quote(in string stock_name, out string stock_name);
Discussion:
-----------
(c) contradicts with the CORBA Messaging Philosophy that AMI is a mere
client-side issue and that in principle any existing target can be called
asynchronously.
(b) means that we would have two different polling-related correlation
mechanisms:
- one for correlating requests and replies in different processes based on the
PersistentRequest objref
- one for correlating requests and replies in the same process based on poller
pointers
(a) means that a generic correlation mechanism is defined that covers both:
intra- and inter-process correlation. This was variant (a) of issue 2803 in the
latest vote. It failed with 5 NO : 4 YES : 3 ABSTAIN.
I could work out two straw men for (a) and (b) for the next vote, or much
better, we could try to discuss this before the next vote and just work out a
straw man for the variant that has better acceptance.Resolution: This issue is obsolete, since PollableSet is now a local object, and valuetype arguments are not copied when passed to local objects. So the exact same valuetype instance registered with add_pollable() will be returned by get_ready_pollable(). So close no change with this explanation
I set out reading ptc/2000-04-05 to answer a question: how could a
client interceptor for the OTS implement the proper behavior for the DII
get_response or get_next_response operations that require the
WrongTransaction to be raised if the current thread is not properly
associated with the same transaction as the request.
I wasn't able to answer this question authoritatively, because there is
nothing in the Portable Interceptors Chapter that indicates the proper
time sequencing of when the client side request interceptor operations
are invoked in relation to the use of the DII (or the AMI_ messaging
interfaces either.)
By inference, it appears to me that the only way to allow an OTS client
request interceptor to exhibit the proper semantics is for the ORB to
not make calls to receive_{reply,exception,other} when the response is
received from the protocol stack, but instead to make them when
get_response or get_next_response is called by the application.
This paragraph in 21.3.7.2:
"Asynchronous requests are simply two separate requests. The first
request receives no reply. The second receives a normal reply. So the
normal (no exceptions) flow is: first request - send_request followed by
receive_other; second request - send_request followed by receive_reply."
is also not particularly useful, since it doesn't give any indication
how the interceptor can distinguish the "first request" from the "second
request".
So, to sum up, the PI chapter needs explicit information showing the
time sequencing of when the request interceptor operations are invoked
in relationship to a static call, a DII call, and AMI_ calls.
Resolution: Clarify as suggested in the archive. Also fix 5743 with this The basic fix for this issue consisting of items 1 through 5 below fixes item 2 of 5743 since the interceptor can now check inside the send_poll interception point that the RSC transaction context is compatible with the TSC transaction context. Items 6 through 9 fixes item 1 of issue 5743.
The text in section 9.2.3 / page 9-71 describing the arguments attribute to ORBInitInfo could use some more precise wording. It reads: "This attribute contains the arguments passed to ORB_init. They may or may not contain the ORB's arguments." I take this to mean that any ORB_init arguments that applied to the ORB instance being created may not be present. All other strings passed to ORB_init will be present so initialisation strings can be passed to the interceptors through ORB_init. With the current text it is possible to think that you may not get *any* of the arguments to ORB_init.
Resolution: Issue 5690 addresses this in a more specific focused way. So close this issue and merge its discussion into 5690.
it appears to be impossible to portably attach OTS policies to POAs with the machinery that is currently in place. We need a fix for that, otherwise OTS ends up getting hamstrung...
Resolution: No problem in doing that. A policy is created which is handed in the PolicyList tocreate_POA. When the IORInterceptor is called get_server_policy (or whatever the API call is) retrieves the policy, if present, and establish_component is called with the REQUIRES_SHARED component. Now, a couple of anciliary things need to be fixed: 1. Remove the requirement for the registration of policy factory in section 21.5.5.1 "get_effective_policy". 2. Clarify in an appropriate place that the source of server side policies that get placed in a IOR is the POA that the IOR is created from. Both of these have already been taken care of by resolution of other issues and the current text in section 21.5.5.1 already fixes these concerns. So close this issue no change
(All document refs to ptc/00-04-05)
Sec. 4.3.7.1 (Object::get_policy) talks about "the Policy as specified in
the IOR". Policies get translated to IOR components, but AFAIK there's no
general way that a component can be unscrambled to give a Policy. This
suggests that we need another interception point, effectively the inverse of
the existing IORInterceptor (sec. 21.5), that allows an IOR component to be
converted into a Policy on the client side.
I suggest something like:
local interface ReceiveIORInterceptor : Interceptor {
void establish_policies (in ReceiveIORInfo info);
};
local interface ReceiveIORInfo {
CORBA::Policy set_policy (in CORBA::Policy policy);
IOP::TaggedComponent get_ior_component ();
IOP::TaggedComponent get_ior_component_from_profile (
in IOP::ProfileId profile_id);
};
and an extra operation add_receive_ior_interceptor in ORBInitInfo.
ReceiveIORInterceptor::establish_policies provides the opportunity for an
interceptor to turn IOR components back into Policies, using the
interceptor's Policy Factories directly or indirectly via
ORB::create_policy.
The ORB will call this method on all registered ReceiveIORInterceptor
objects during or before the first call of Object::get_policy (we needn't be
more specific - this would allow eager calls on unmarshalling or lazy calls
within Object::get_policy).
Issue 4065 covers this issue in greater generality. Merge this issue into 4065 and close this issue
I am in the process of implementing Portable Interceptors within a C++
ORB,
and I would like to raise an issue for resolution regarding the semantics
of the
"register_initial_reference()" function, particularly with respect to the
memory
management of the object being registered.
The interface for this function is as follows:
void register_initial_reference (
ObjectId id,
Object_ptr obj
);
Within the Portable Interceptors specification, there is really no
information about
how the memory for the object should be managed. For example, does the
caller of
"register_initial_reference()" pass ownership of the object to the ORB, or
not?
Also, does the caller of "resolve_initial_references()" gain ownership of
the object
which is returned, or not?
Here is my proposed resolution:
The fact that the "obj" parameter is a CORBA::Object implies that it is a
reference-counted
object. Therefore, it would make sense that when
"register_initial_reference()" is called, the
ORB performs a "_duplicate()" on the object to increment its reference
count (the ORB would
then hold its own reference count). The caller of
"register_initial_reference()" can decide
whether to call "release()" or retain its own reference count.
Later, when "resolve_initial_references()" is called, the ORB would call
"_duplicate()" on the
object prior to returning it to the caller, thereby giving the caller its
own reference count.
The caller would then need to call "release()" when it is finished with
the object.
When the ORB is deleted, it must clean up the lookup table of registered
objects. To do this,
it simply calls "release()" on each one, and if no one else holds a
reference count, then
the object is simply deleted.
I would like the hear other people's thoughts on this, particularly those
who have done or are
working on a C++ implementation of PI.Resolution: No need to say anything regarding this in the Core spec. As for language mapping specs traditionally, when no special mapping is provided for something in a PIDL it is assumed that it uses the general language mapping. So most likely nothing needs to be said there either. So close no change.
Using the static invocation interfaces, it is possible to receive a valuetype that derives from the one declared in an operation, as long as a valuetype factory is known in the receiver (truncation is not the issue here). The same is not possible at the DII: When creating the request, the caller must indicate what type it expects, by forming a named value. Conceptually, the typecode in the named value should be the typecode of the base of all acceptable value types. However, if the ORB receives a derived type, it has no means of unmarshalling it - even if the application has knowledge about the derived type. What is missing is an interface to make typecodes of value types known to the ORB; with those, the ORB could then understand the CDR of the valuetype, and create a DynAny when asked to.
This problem comes from the fact that RoutingPolicy is actually a range: min and max. Basically, Messaging defines this range of Routing QoS: ROUTE_NONE(0) ---> ROUTE_FORWARD(1) ---> ROUTE_STORE_AND_FORWARD(2) You can set your min and max to any of the values, with the caveat that min must be <= max. The issue that concerns us is when the min is ROUTE_NONE(0) and the max is either ROUTE_FORWARD(1) or ROUTE_STORE_AND_FORWARD(2). If you look at the Messaging spec (orbos/98-05-06) in section 5.3.5.3, it says: "If, for example, the min is ROUTE_NONE and the max is ROUTE_FORWARD, the Routing protocol will normally be used but a direct connection may be used if available." Of course, we've left in "usually" just to make sure we could screw up OTS for you :) Reading the text in section 3.3 makes me believe that an issue should really be raised in the Messaging-RTF to clarify this. Here's what I BELIEVE the results would be for all of the combinations. min maxresultconfidence ----------- ---------- -------------------- ROUTE_NONEROUTE_NONEDirect Call100% ROUTE_NONEROUTE_FORWARDTII if possible50% direct if not ROUTE_NONEROUTE_STORE_AND_FORWARDTII if possible50% direct if not ROUTE_FORWARDROUTE_FORWARDTII Only100% ROUTE_FORWARDROUTE_STORE_AND_FORWARDTII Only100% ROUTE_STORE_AND_FORWARDROUTE_STORE_AND_FORWARDTII Only100% Obviously, the problem is with cases #2 and #3. How should an ORB determine which to use: what priority is given to each of the RoutingType values?
Resolution: It is not clear that the exact algorithm needs to be specified in the standard, and it appears to be the case that it was left intentionally open. Absent a strong reason for specifying more details in this area, close this issue no change.
looking at the POA IDL, I get the impression that it was written at a time
where the use of multiple ORBs in a process wasn't anticipated. With
the advent of messaging, OTS, QoS policies, etc, it is more and more common
for one application to use several ORBs simultaneously.
When writing code, it becomes an endless pain dealing with multiple ORBs.
That's because I have to endlessly pass the ORB around in my program, just
so I can do things like call object_to_string() or string_to_object(), etc.
I think it would be really useful to have an ORB() accessor on the POA
interface:
interface POA {
CORBA::ORB ORB();
// ...
};
The accessor would return the ORB for this POA. Doing this would eliminate
most of the cases in my code where I have to pass the ORB around. For
example, in a servant, I can call _default_POA(), and then call ORB() to
get at the ORB.
Adding the operation would cause any compatibility problems, I believe.
Opinions?
Resolution: Access to ORB is to be provided by adding an ORB accessor operation to the Object interface. This has the virtue of keeping the PIDL-ness of the ORB contained by the PIDL-ness of the Object interface, and yet allows straightforward way of providing access to the ORB from any object local or otherwise. Since both PI and POA are local interfaces, this automatically provides a means of accessing the ORB from these, and consequently also provides a means for getting access to all ORB operations from these local objects and hence addresses the concerns raised in issues 3403, 3793 and 3322. So all these issues should be resolved in a single block and closed simultaneously with this issue. This resolution will require the definition f language mapping of the new extended Object interface. The resolution of this issue shall be conditional upon the availability of at least one language mapping for the extended Object interface.
There is currently no way to register a value factory from an ORB initializer.
Resolution: Adding an accessor to the ORB in the Object interface together with having that accessor return the relevant ORB for relevant local objects like the ORB initializer provides the least obtrusive way to give access to the value factory regstration facility of the ORB. This is proposed as resolution for issue 3772. So this issue is simultaneously resolved with issue 3772. Care must be taken in the resolution of 3773 to define precisely which ones of the ORB's operations will be available from the ORB initializer. The rest will return the NO_IMPLEMENT exception.
Issue on Document orbos/2000-08-04, CSIv2 Joint Submission
Document: orbos/2000-08-04, CSIv2 Joint Submission
Subject: Identity Assertion of X.501 Distinguished Name is not good enough
Severity: Critical
Summary:
The Identity Token union contains a branch that is labled
X501DistinguishedName. A single DN is insufficient to identify an entity.
A path of X501Distinguished Names is needed instead. Also, other concerns
about naming types are raised.
Discussion:
An X.501 Distinguished Name is insufficient to identify a single entity.
The name must be accompanied by the name of its defining authority. In the
case of public key certificates, the names certificate authority must be
included.
The chain of DNs in this manner must be included up to a root authority
to have any definitive meaning.
This approach will be consistent with the client sending a X.509
Certificate Chain. A DN path is actually defined by the certificate chain.
Furthermore, the DN path should only come from an authority that is
acceptable to the server, whether it be a DN path, or an X.509
Certificate Chain.
The IOR should list the acceptable authorities and their name types.
It is becoming more an more evident that we must invent GSS_NT_Export_Name
types for X.509 Certificate Chain and X.501 DN path.
The SAS_ContextSec structure should list, instead of the naming types,
the naming authorities!
We shall assume that the name types of the asserted identities shall be
the same as the name types of listed naming authorities in the IOR.
This is the only way this procedure can work Interoperable and without
the client Guessing what it should do.
Suggestions:
An OID for an X.509 Public Key Certificate Chain shall be defined for a
GSS Export Name, and its encoding will be a ASN1 sequence of and X.509
certificate with the least significant certificate first.
An OID for an X.501 Distinguished Name Path shall be defined for a GSS
Exported Name, and its encoding shall be an ASN1 sequence of an X.501
Distinguished Name with the least significant name first.
To avoid having the target put a whole certificate chain in its IOR,
a new OID shall be allocated in which its GSS Exported Name encoding is a
X.501 DN path, but stipulates that the client should send a certificate
chain from that named authority. This GSS Exported Name shall only be
used in IORs and not for transmission in the Identity Token.
typedef Security::GSS_NT_ExportedName NamingAuthority;
struct CompoundSecMech {
Security::AssociationOptions target_requires;
IOP::TaggedComponent transport_mech;
sequence<ServiceConfiguration> privilege_authorities;
sequence<NamingAuthority> naming_authorities;
};
Minor codes specifications are missing in all the places where the specifications states that a system exception is to be raised. The minor codes need to be specifiedto complete the specification of exceptional beahivior.
Resolution: In formal/02-06-01 there are the following occurences of rasing of a standard system exception that do not mention any minor code:
1. Section 22.9 OBJECT_NOT_EXIST
2. Section 22.10.1.1 TIMEOUT and NO_RESPONSE
3. Section 22-10.1.2 TIMEOUT and NO_RESPONSE
4. Near the top of page 22-31 TIMEOUT and NO_RESPONSE
5. Near bottom page 22-30 OBJECT_NOT_EXIST
6. 22.14.2.9 OBJECT_NOT_EXIST
7. Page 22-60 TRANSACTION_ROLLEDBACK (twice)
8. Page 22-62
9. Section 22.9 BAD_INV_ORDER
The following are the description of conditions that these exceptions represent:
1. The is_ready operation of the Poller object is invoked after the reply has already been picked up from the Poller.
This needs a new minor code.
2. TIMEOUT when the reply is not available in the Poller by the timeout set for it.
NO_RESPONSE reply is not available immediately in a non-blocking call
These need new minor code, and same ones apply for items 3 and 4.
3. TIMEOUT and NO_RESPONSE same as for 2 above but applies to the read/write attributes of Poller. 2 refers to operations of the Poller.
Same minor code as for item 2.
4. TIMEOUT and NO_RESPONSE same as for 2 above but applies to the read only attributes of Poller.
Same minor code as for item 2.
5. The same as 1.
6. The same as 1.
7.The Router raise TRANSACTION_ROLLEDBACK to reflect that a deferred transaction was rolled back.
New minor code.
8. ReplyHandler raises TRANSACTION_ROLLEDBACK when it wishes to rollback the Router's transaction.
Don't need a new minor code. the ReplyHandler is implemented by the user, so it should be allowed to provide its own unique minor code.
9. is_from_poller raises BAD_INV_ORDER if the Poller has not returned any response yet.
New minor code.
I'd like to raise an issue and garner feedback on the interaction of the
Messaging timeout QoS policies (or indeed any proprietary invocation
timeout mechanism) and portable interceptors.
Where a bound is being imposed on request and/or reply delivery, and
portable interceptors are present in the client- and/or server-side
binding, these interceptors surely must be made aware of the relevant
timeout(s) so that they may bound any potentially blocking activities
they engage in. Assuming that it would be unacceptable to dictate that
potentially blocking activity (such as making a subsidiary invocation)
may not be undertaken in interception point operations, it appears some
addition to the PortableInterceptor::RequestInfo interface is required
to facilitate the Messaging timeout policies at least. For instance, the
absolute request and reply expiry times could be passed as additional
attributes:
module PortableInterceptor
{
interface RequestInfo
{
// ...
readonly attribute TimeBase::UtcT request_end_time;
readonly attribute TimeBase::UtcT reply_end_time;
};
};
the former bounding the send_request, send_poll,
receive_request_service_contexts and receive_request interception points
and the latter bounding the send_reply, send_exception, send_other,
receive_reply, receive_exception and receive_other interception points.
Of course this all relies on the discipline of the portable interceptor
implementor, i.e. that they do not ignore the constraints imposed by the
timeouts.
Resolution: a PI implementation can just use ClientRequestInfo::get_request_policy on the client side or RequestInfo::get_request_service_context on the server side to query the timeout policy values directly if it needs to. Close no change
For instance, OTS has a policy called OTSPolicy. This policy is encoded in an IOR component with component id TAG_OTS_POLICY. This policy governs how transactions are handled when invocations are made on the object reference. Problem: As an end user I would like to be able to interrogate the value of this policy. I would expect to be able to call CORBA::Object::_get_policy with the OTS PolicyType identifier to retrieve the OTSPolicy and subsequently determine the value. However, at present there is no portable way to turn this IOR component into a policy.