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

;

local interface PriorityModelPolicy : CORBA::Policy

;

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

Closed, no change

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

;

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.

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

Accept as specified

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

; local interface RTORB

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

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

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

; This is ok in 2.16 but not ok in 2.6

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

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

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

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

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 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?