Real-time CORBA Avatar
  1. OMG Specification

Real-time CORBA — Open Issues

  • Acronym: RT
  • Issues Count: 20
  • Description: Issues not resolved
Open Closed All
Issues not resolved

Issues Descriptions

Small typo in the RT CORBA chapter of the CORBA/IIOP 2.4 spec

  • Key: RT11-1
  • Legacy Issue Number: 4394
  • Status: open  
  • Source: University of California, Irvine ( Carlos O'Ryan)
  • Summary:

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

  • Reported: RT 1.0 — Wed, 20 Jun 2001 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

Fig. 5.5

  • Key: RTC11-1
  • Legacy Issue Number: 15262
  • Status: open  
  • Source: Kenya Bureau of Standards ( Zacharia Chepkania)
  • Summary:

    Fig. 5.5, Although it is repeated and emphasized under Error Handling subtitle (on page 15), I propose that the following words "reset_component" be added on the return path from Error[1], Error[2], and Error[3] to Inactive[1], Inactive[2] and Inactive[n] respectively. There is no harm in repeating the same as long as it makes the specification clear to understand.

    General Comment: I propose the inclusion of a chapter on "Definitions" of some terms that may not seem obvious to some developers/users. May be it is not a requirement by OMG, but it is the International Practice to define some terms in such a specification.

  • Reported: RTC 1.0 — Tue, 25 May 2010 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

Ambiguous "SUCCESS" message in RT-CORBA priority bands

  • Key: RT11-2
  • Legacy Issue Number: 4350
  • Status: open  
  • Source: University of California, Irvine ( Carlos O'Ryan)
  • Summary:

    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.

  • Reported: RT 1.0 — Mon, 18 Jun 2001 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

Change heading "Ownership and Participation" to "Participation"

  • Key: RTC11-5
  • Legacy Issue Number: 16622
  • Status: open  
  • Source: AIST ( Geoffrey Biggs)
  • Summary:

    The heading "Ownership and Participation" should be changed to "Participation" to reflect the new relationship between LightweightRTObjects and ExecutionContexts.

  • Reported: RTC 1.0 — Tue, 18 Oct 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Remove get_owned_contexts() method from LightweightRTObject (section 5.2.2.2.8)

  • Key: RTC11-4
  • Legacy Issue Number: 16621
  • Status: open  
  • Source: AIST ( Geoffrey Biggs)
  • Summary:

    Section 5.2.2.2.8 should be removed to reflect the get_owned_contexts() method being removed.

  • Reported: RTC 1.0 — Tue, 18 Oct 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Remove the get_owned_contexts() method from the LightweightRTObject interface

  • Key: RTC11-9
  • Legacy Issue Number: 16626
  • Status: open  
  • Source: AIST ( Geoffrey Biggs)
  • Summary:

    Remove the get_owned_contexts() method from the LightweightRTObject interface.

  • Reported: RTC 1.0 — Tue, 18 Oct 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Remove the "owner" field from the ExecutionContextProfile structure

  • Key: RTC11-8
  • Legacy Issue Number: 16625
  • Status: open  
  • Source: AIST ( Geoffrey Biggs)
  • Summary:

    The ExecutionContext will not be owned by a LightweightRTObject, so the "owner" field should be removed from the ExecutionContextProfile structure.

  • Reported: RTC 1.0 — Tue, 18 Oct 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Change relationship between ExecutionContext and LightweightRTC

  • Key: RTC11-2
  • Legacy Issue Number: 16619
  • Status: open  
  • Source: AIST ( Geoffrey Biggs)
  • Summary:

    In Figure 5.3, ExecutionContext may be a composite member of a LightweightRTC. This relationship will be removed. RTCs will not own ECs, they will only participate in them.

  • Reported: RTC 1.0 — Tue, 18 Oct 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Remove the first paragraph under "Ownership and Participation"

  • Key: RTC11-6
  • Legacy Issue Number: 16623
  • Status: open  
  • Source: AIST ( Geoffrey Biggs)
  • Summary:

    The first paragraph under "Ownership and Participation" should be removed, as LightweightRTObjects will not own ExecutionContexts if other changes are approved.

  • Reported: RTC 1.0 — Tue, 18 Oct 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Remove get_owned_contexts() method from LightweightRTObject

  • Key: RTC11-3
  • Legacy Issue Number: 16620
  • Status: open  
  • Source: AIST ( Geoffrey Biggs)
  • Summary:

    The get_owned_contexts() method shall be removed. RTCs will no longer be able to own ECs, they will only participate in them.

  • Reported: RTC 1.0 — Tue, 18 Oct 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Change "An autonomous RTC" to "An RTC"

  • Key: RTC11-7
  • Legacy Issue Number: 16624
  • Status: open  
  • Source: AIST ( Geoffrey Biggs)
  • Summary:

    Change "An autonomous RTC" to "An RTC" under "Ownership and Participation".

  • Reported: RTC 1.0 — Tue, 18 Oct 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Remove the "owner" member from the ExecutionContextProfile structure

  • Key: RTC11-10
  • Legacy Issue Number: 16627
  • Status: open  
  • Source: AIST ( Geoffrey Biggs)
  • Summary:

    Remove "RTObject owner;" from the ExecutionContextProfile struct.

  • Reported: RTC 1.0 — Tue, 18 Oct 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 2.15.1 Proposal to extend the TCPProtocolProperties to the definition below

  • Key: RT12-8
  • Legacy Issue Number: 12911
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Proposal to extend the TCPProtocolProperties to the definition below. Add debug/host/port. debug to control SO_DEBUG. host/port to limit a POA to a certain host/port number local interface TCPProtocolProperties : ProtocolProperties

    { attribute string host; attribute unsigned short port; attribute long send_buffer_size; attribute long recv_buffer_size; attribute boolean keep_alive; attribute boolean dont_route; attribute boolean no_delay; attribute boolean debug; }

    ;

  • Reported: RT 1.1 — Mon, 6 Oct 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:51 GMT

Section: 2.6 Real-time Current

  • Key: RT12-7
  • Legacy Issue Number: 12590
  • Status: open  
  • Source: Micro Focus ( Simon McQueen)
  • Summary:

    In this section, which describes the RTCORBA Current, the attribute thereon that holds the thread's priority is said to be called: 'base_priority'. In the consolidated IDL and separate IDL download no such attribute exists. Current has instead an attribute 'the_priority'. Seems an obvious error - just need to call for one or the other.

  • Reported: RT 1.2 — Tue, 29 Jul 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:51 GMT

Section: 2.10.1

  • Key: RT12-3
  • Legacy Issue Number: 9019
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Dynamic threads in RTCORBA Threadpools. With RTCorba it is possible to create thread pools with dynamic threads. These threads may be additionally created by the ORB when needed. But the spec says about the destruction that it is an implementation issue, but it is really the application programmer that can make a decission about this instead of just the ORB. The only real possible option an ORB builder has is to keep the thread alive or destroy it after each invocation. We propose to extend the RTCORBA interface with an interface that is called back by the ORB so that it is to the application programmer to decide what should be done with the thread. Below is a possible proposal: This is the current implementation and the CORBA spec says it is up to the implementor, but it is now up to the ORB builder, not to the application programmer who is the correct person to decide what the do with a dynamic thread. To be able to let the application programmer decide this we need a special callback interface. A proposal would be to add the following: module RTCORBA { local interface DynamicThreadManager

    { bool check_dynamic_thread (in ThreadPoolId threadpool, in unsigned long current_threads); bool check_dynamic_thread_in_lane (in ThreadPoolId threadpool, in ThreadPoolLane lane, in unsigned long current_threads); }

    ; local interface RTORB

    { ... set_dynamic_thread_manager (in DynamicThreadManager manager); ... }

    ; }; At the moment the ORB decided that a dynamic thread is not needed anymore, it will callback to the application programmer. It is now up to the application programmer what to do, when returning true it will keep the thread alive, if false, it will end the thread.

  • Reported: RT 1.1 — Tue, 27 Sep 2005 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:51 GMT

Section: 2.6

  • Key: RT12-2
  • Legacy Issue Number: 8865
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    RTCurrent is defined as following: local interface Current : CORBA::Current

    { attribute Priority base_priority; }

    ; But it should be: local interface Current : CORBA::Current

    { attribute Priority the_priority; }

    ; This is ok in 2.16 but not ok in 2.6

  • Reported: RT 1.1 — Wed, 8 Jun 2005 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:51 GMT

Section: section1.5 and section 2

  • Key: RT12-1
  • Legacy Issue Number: 8767
  • Status: open  
  • Source: Department of Computer Science, National University of Defense Technology,china ( YUAN Hong-Liang)
  • Summary:

    The applications based on Real-Time CORBA need analyze request header in order to get the request priority embedded in request header. Before analyzing request header, server-side ORB can not know the priority of request. In multi-threaded ORB, there are many threads serving client’s requests concurrently. At the same time there is at least one thread which takes in charge receiving requests from network and identifying the priority of request ( below we refer to this thread as endpoint-thread, and refer to the thread serving request as request-thread ). It is very important that what priority we should set to the endpoint-thread. If endpoint-thread priority is too high, it will impact the execution of request-thread, that is to say, impact the process of received request. If endpoint-thread priority is too low, it cannot receive new request from clients, which may be urgent request, compared to current requests. So we suggest providing a priority policy, maybe it can be named EndpointThreadPriorityPolicy, which allowing user to set endpoint-thread priority according to his requirement. ORB should provide default priority value for EndpointThreadPriorityPolicy. Below is the possible idl interface: //idl module RTCORBA { //local interface EndpointThreadPriorityPolicy : CORBA::Policy

    { attribute Priority endpoint_thread_priority; }

    ; }; Applications can use this policy at the time of creating POAMananger. For example:(in win32 REALTIME_PRIORITY_CLASS) //c++ CORBA::PolicyList pl; pl.length(1); pl[0] = rtORB >create_endpoint_thread_priority_policy(24); PortableServer::POAManager_var manager = poamanager_factory> create_POAManager("RootPOAManager",pl); through configuring endpoint_thread's priority, we can trade off the processing between rceived request and new arrival request .

  • Reported: RT 1.1 — Thu, 5 May 2005 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:51 GMT

idl for RTCORBA::Current - page2-9

  • Key: RT12-6
  • Legacy Issue Number: 10141
  • Status: open  
  • Source: ADLINK Technology Ltd ( Steve Osselton)
  • Summary:

    The idl for RTCORBA::Current on this page is: module RTCORBA { local interface Current : CORBA::Current

    { attribute Priority base_priority; }

    ; }; Whereas in the consolidated IDL the attribute name is actually 'the_priority' not 'base_priority'. All ORBs appear to have implemented using 'the_priority' IMHO this is a simple editorial fix.

  • Reported: RT 1.1 — Fri, 25 Aug 2006 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:51 GMT

Section: 2.10

  • Key: RT12-5
  • Legacy Issue Number: 9022
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    At the end of 2.10 it says: The same threadpool may be associated with a number of different POAs, by using a ThreadpoolPolicy containing the same ThreadpoolId in each POA_create. POA_create should be create_POA

  • Reported: RT 1.1 — Wed, 28 Sep 2005 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:51 GMT

Section: 2.4

  • Key: RT12-4
  • Legacy Issue Number: 9020
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The RTCORBA::Priority type has the allowed values of 0-32767 but is defined as short, which is signed. Shouldn't we define it as unsigned short?

  • Reported: RT 1.1 — Tue, 27 Sep 2005 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:51 GMT