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

Issue 2905: setting of ORB level policies unclear
Issue 3452: No factory for protocol properties
Issue 3453: Documentation of GIOPProtocolProperties
Issue 3454: Policy overrides on RTCORBA::Current
Issue 3455: Policy overrides on RTCORBA::RTORB
Issue 3456: Policy overrides on RTPortableServer::POA
Issue 3457: Definition of "the_priority" ambiguous and incomplete
Issue 3583: default priority transform
Issue 3584: Success of activate_object_id_with_id_and_priority
Issue 3585: calling of Priority Transform outside of context of an invocation
Issue 3594: Modify document in accordance with changes from Components
Issue 4350: Ambiguous "SUCCESS" message in RT-CORBA priority bands
Issue 4394: Small typo in the RT CORBA chapter of the CORBA/IIOP 2.4 spec

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