Issues for Realtime CORBA FTF 1.2 discussion list

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

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

Jira Issues

Issue 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)

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).