Issue 2905: setting of ORB level policies unclear Jira Issue RT-3
Issue 3452: No factory for protocol properties Jira Issue RT11-3
Issue 3453: Documentation of GIOPProtocolProperties Jira Issue RT11-4
Issue 3454: Policy overrides on RTCORBA::Current Jira Issue RT11-5
Issue 3455: Policy overrides on RTCORBA::RTORB Jira Issue RT11-6
Issue 3456: Policy overrides on RTPortableServer::POA Jira Issue RT11-7
Issue 3457: Definition of "the_priority" ambiguous and incomplete Jira Issue RT11-8
Issue 3583: default priority transform Jira Issue RT11-9
Issue 3584: Success of activate_object_id_with_id_and_priority Jira Issue RT11-10
Issue 3585: calling of Priority Transform outside of context of an invocation Jira Issue RT11-11
Issue 3594: Modify document in accordance with changes from Components Jira Issue RT11-12
Issue 4350: Ambiguous "SUCCESS" message in RT-CORBA priority bands Jira Issue RT-1
Issue 4394: Small typo in the RT CORBA chapter of the CORBA/IIOP 2.4 spec Jira Issue RT-2
Issue 2905: setting of ORB level policies unclear (rt-corba-ftf)
Click here for this issue's archive.
Source: Real-Time Innovations (Mr. Dave Stringer, dstringer(at)rti.com)
Nature: Uncategorized Issue
Severity:
Summary:
The Real-Time CORBA Extensions don't state how an ORB level policy setting is made (e.g. for a default threadpool). ptc/99-06-02 See 4.10.4 states that this should be possible. The mechanism wasn't specified since at the time Real-Time CORBA was written it was assumed that CORBA 2.3 would use the QoS / Policy framework from Messaging. I.e. by calling PolicyManager::set_policy_overrides - orbos/98-05-05 Sec 5.2. Instead we have a pretty vague piece of specification Sec 4.9.4 of formal/99-07-08. This doesn't help implementors of Real-Time CORBA.
Resolution : Add the words "by using the set_policy_overrides operation of the CORBA PolicyManager interface" to the first sentence of the second paragraph in section 4.10.4, on page 48 of ptc/99-06-02, and break it up into two shorter sentences. Disposition : Accepted
There is no standard factory method for users to create ProtocolProperties, TCPProtocolProperties, or GIOPProtocolProperties.
GIOPProtocolProperties no stated purpose. This needs to be clarified in the specification.
It is implicit that you can override policies on RTCORBA::Current since it inherits from CORBA::Object. This should be explicitly stated.
Resolution: Close this issue without change. There is no reason to use the CORBA::Object::set_policy_overrides operation on RTCORBA::Current. Real-Time CORBA policies are overridden at the Current scope using the PolicyCurrent object. Disposition : Rejected
It is implicit that you can override policies on RTCORBA::RTORB since it inherits from CORBA::Object. This should be explicitly stated.
Summary: It is implicit that you can override policies on RTCORBA::RTORB since it inherits from CORBA::Object. This should be explicitly stated. Resolution: Close this issue withougt change. There is no reason to use the CORBA::Object::set_policy_overrides operation on RTCORBA::RTORB. Real-Time CORBA policies are overridden at the ORB scope using the ORB-scope PolicyManager. Disposition : Rejected
It is implicit that you can override policies on RTPortableServer::POA since it inherits from CORBA::Object. This should be explicitly stated.
The specification implies but does not clearly state that the "the_priority" attribute of the RTCORBA::Current local interface should set and get the base priority of the thread. I suggest that the following three modifications to the specification: 1. change the name of the "the_priority" attribute to "base_priority"; 2. add another priority attribute to RTCORBA::Current called "active_priority"; and 3. replace the second paragraph in section 4.6 which currently reads: A Real-Time CORBA Priority may be associated with the current thread, by setting the priority attribute of the RTCORBA::Current object: with: There are two views of CORBA priority for a given thread: the base priority and� the active priority. The base priority is the priority that application code explicitly sets. The active priority is the priority the thread is currently running at. Note that the active priority may temporarily be higher than the base priority because of temporary priority boosts caused by either the ORB's or the O/S's resource protection mechanisms. There are two attributes in the RTCORBA::Current interface for setting and getting these two views of priority:
The first paragraph on page 41 says that : 'A Real-Time ORB shall provide a default transform. Furthermore, a Real-Time ORB shall provide a mechanism to allow users to override the default priority transform with a priority transform or their own.' The second statement is true, but the first is not. (That is, we did not decide that there would be such a thing as a default priority transform.) The priority transform mechanism was specified in order to allow users to install their own modifiers to the two Real-Time CORBA Priority Models. By default, no transform is required. Therefore, I propose that we drop the first sentence, and change the second one to make its point correctly : Proposal : Change this paragraph to : 'A Real-Time ORB shall provide a mechanism to allow users to install a priority transform'. As this is a single sentence, add it to the end of the following paragraph (which actually introduces it and is therefore better before it.)
The last paragraph on page 39 of ptc/99-06-02 (section 4.7.5) states that 'If the priority value is the same then the ORB shall return SUCCESS.' This is describing behaviour for the operation RTPortableServer:: activate_object_with_id_and_priority, which has a void return type. If this is refering to not throwing an exception, then the wording is not very clear.' Proposal : Change this sentence to : 'If the priority value is the same then the operation will be successful.'
The last sentence of the third paragraph of section 4.8 (on page 40) reads 'If the outbound transform is called outside the context of an invocation then there is no ObjectId and the ORB shall not invoke the transform function.' This sentence is not clear, and sounds almost self-contradictory ('if called ... not invoked...'). I believe what this is trying to say is that the outbound transform is not called for invocations from client application threads. i.e. that it is only called for onward invocations, being made from within servant code. I think that this is actually an arbitrary restriction. It would be acceptable to allow the transform to be called for client-side invocations, as these would be distinguishable by the fact that the passed ObjectId would be null. Even if we want to keep the restriction, I think the wording should be improved. Therefore I have two alternative proposals : Proposal A : (If we want to remove this restriction.) Change this sentence to read : 'For invocations not made from another CORBA Object (i.e. made from an application thread), the outbound transform is still called, with a null value for the ObjectId parameter. The transform implementor has the option of leaving the priority unmodified in this case.' Proposal B : (If we want to keep this restriction) Change this sentence to read : 'The outbound priority transform is not called for invocations made from application threads (i.e. calls that are not made from servant code.)'
Since the Components specification modifies the Real-Time CORBA 1.0 specification we should update the document to reflect the changes.
The RT-CORBA specification, even after the FTF modifications (pt/00-09-02) reads: ----------------------------- 4.12.2 Binding of Priority Banded Connection [6th paragraph] .... Having done this the ORB shall send a "SUCCESS" Reply message. If the..... ----------------------------- No definition for what form this SUCCESS reply should take. One should assume that it is a regular GIOP Reply message, with the reply_status set to NO_EXCEPTION. The spec is at least misleading, should the string "SUCCESS" be returned? Or should a boolean value of "SUCCESS" be returned? Or just returning an empty reply is enough? Suggested fixes: 1) Define the _bind_priority_band() [pseudo?-]operation using IDL, that would at least clarify the contents of all messages, something like the following: module CORBA { // PIDL interface Object { ... .. void _bind_priority_band (); }; 2) Change the paragraph to read: When a Real-Time-ORB receives a _bind_priority_band Request it should allocate resources to the connection and configure those resources appropriately to the priority band indicated in the ServiceContext. Having done this the ORB shall send a GIOP Reply message with the reply_status field set to NO_EXCEPTION.
The CORBA/IIOP 2.4.2 spec (formal/01-02-033) contains a small typo in page 24-21, section 24.13 "Real-Time Current", second paragraph after the code segment. It reads "PrioirtyMapping::to_native" (note the reversed 'ir' in PriorityMapping).