Issues for Real-Time CORBA 1.2 RTF mailing list

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

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

Issue 5613: PriorityModelPolicy
Issue 5949: Minor syntax errors in spec
Issue 8767: Section: section1.5 and section 2
Issue 8865: Section: 2.6
Issue 9019: Section: 2.10.1
Issue 9020: Section: 2.4
Issue 9022: Section: 2.10
Issue 10141: idl for RTCORBA::Current - page2-9
Issue 12590: Section: 2.6 Real-time Current
Issue 12911: Section: 2.15.1 Proposal to extend the TCPProtocolProperties to the definition below

Issue 5613: PriorityModelPolicy (rt-corba-rtf)

RTCORBA::PriorityModelPolicy cannot be created via ORB::create_policy() method because this policy has two attributes <priority_model> and <server_priority> and the Any that is passed to the ORB::create_policy() method can only hold one parameter. Here is the proposed fix: 

struct PriorityModelParameter { PriorityModel priority_model; Priority server_priority; }; 

local interface PriorityModelPolicy : CORBA::Policy { readonly attribute PriorityModelParameter value; }; 

RTCORBA::create_priority_model_policy may also need to be changed (for consistency) to accept <PriorityModelParameter> rather than the two parameters separately. 

An alternative method for creating the PritorityModelPolicy exists, create_priority_model_policy.

These should be editorial changes:


Section 2.7.4 Server Declared Priority Model


ObjectId activate_object_with_priority (
                in PortableServer::Servant p_servant,
                in RTCORBA::Priority priority )
        raises ( ServantAlreadyActive, WrongPolicy );


Should be:


PortableServer::POA::ObjectId activate_object_with_priority (
                in PortableServer::Servant p_servant,
                in RTCORBA::Priority priority )
        raises ( PortableServer::POA::ServantAlreadyActive,
                 PortableServer::POA::WrongPolicy );

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 .

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

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. 

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? 

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

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. 

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.

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; };