This page contains a list of known RTCORBA-related issues and to-do items. The list does not include any of the reports from the bug tracking system, so be sure to query Bugzilla for RTCORBA entries. (At the time of writing, there was one RTCORBA Bugzilla entry, #737.)
ptc/99-05-03 does not specify PolicyType values for RTCORBA policies, so we are using arbitrary values in TAO. When OMG makes standard PolicyTypes available, we'll need to update TAO.
Files to update: orbconf.h and RTCORBA.*
RTCORBA::ServerProtocolPolicy and RTCORBA::ClientProtocolPolicy allow application developers to select and configure ORB communication protocols, and to specify preferred order of their use. This functionality has been implemented in TAO, but is only available when RTCORBA is enabled. Since protocol management is of interest to a large chunk of TAO users (many of whom do not need RTCORBA otherwise), we should make protocol policies available even when RTCORBA is disabled, better integrate them with the Pluggable Protocols framework, and provide a number of other enhancements.
Following the examples of FT, PortableServer and others, we should factor out RTCORBA-specific code into a separate library, for all the same good reasons.
Current version of Implementation Repository does not work properly with RTCORBA or Pluggable Protocols because it does not handle multiple endpoints for one server. Once RTCORBA implementation is complete, we should look into redesign of Implementation Repository.
Current implementation of Priority Banded Connections in TAO is not interoperable. TAO does not use _bind_priority_band operation and
RTCorbaPriorityRange service context during band establishment. Instead,
the server embeds a proprietary TAO_TAG_ENDPOINTS tagged component into
an object's
IOR to let the clients know about available priorities and corresponding endpoints. To
establish a banded connection, the client simply uses the endpoint corresponding
to the priority of interest. (See TAO Real-Time Architecture section for more
details.)
We can provide an alternative interoperable implementation of Priority Banded Connections by
bind_priority_band operation and
RTCorbaPriorityRange service context during band establishment bind_priority_band
request and/or RTCorbaPriorityRange service context TAO-proprietary Client_Priority_Policy is no longer needed - RTCORBA policies provide the same functionality and more! The policy is not enabled in TAO by default, and when it is manually enabled, RTCORBA policies cannot be used with it. We should remove Client_Protocol_Policy and all related code from TAO before the next release.
Involved files: TAO.pidl, Client_Priority_Policy.* Policy_Manager.*, orbconf.h, Stub.*, Invocation_Endpoint_Selectors.*, ORB_Core.*, tests/Endpoint_per_Priority/*
In RTCORBA tests involving priorities, we are using SCHED_OTHER scheduling class rather than SCHED_FIFO .
This is for convenience: no super-user
privileges are
required, and we can run the tests in our daily builds.
On Solaris, the following code
int max_priority = ACE_Sched_Params::priority_max (ACE_SCHED_OTHER); int min_priority = ACE_Sched_Params::priority_min (ACE_SCHED_OTHER);
produces min_priority of -60 and max_priority of 60. With Direct Priority Mapping, these native priorities map to CORBA priorities 0 to 120. However, if we try to set a thread's priority to CORBA priority 0, i.e., native priority -60, the call fails. In general, calls with negative native priorities fail, and calls with positive native priorities succeed.
When running the tests on Solaris, we use CORBA priority values greater than 60 to get around the problem. However, one would expect that using any of the valid CORBA priority values for the OS/scheduling class should work.
I am not sure what the proper resolution is, e.g., whether this is
ok/correct and just needs to be documented, or whether we should be using some
methods different from ACE_Sched_Params::priority_max and priority_min to obtain
the valid priority range for a given OS/scheduling class, etc. We need to check
this out.
Some of the RTCORBA tests rely on ORB debugging output for checking whether something works. This is very brittle since ORB developers frequently add/remove/modify debugging messages, causing tests to 'break', and increasing amount of maintenance effort required. Yet, we somehow need to verify that internally the ORB behaves as we expect, e.g., a particular transport protocol is used to carry out an invocation. It may be possible to achieve this without depending on ORB debug messages by using Portable Interceptors or some other similar mechanism. For example, we could write several interceptors, which would obtain and print information of interest for the test. We should look into this.
We do have tests for RTCORBA features, but what we also need are some examples. Use case-driven examples illustrating how certain features help satisfy various requirements. Examples that would help users understand when to use various features.
Currently, when the object that has private connections is destroyed, its connections remain in the cache. We need to implement cleanup of private connections on object destruction. If such cleanup is expensive, we may want to have it controlled by an option.
Current client profile management code needs to change for the following reasons:
profile_in_use, profile_sucess and forward_profiles,
is stored per Stub. This assumption no longer holds true, e.g.,
different threads may have different policies set, and would want to use
different profiles based on those policies. This is at least the case with
RTCORBA, where different threads may, for example, want to use different
protocols. It may also be the case in other scenarios. So, we should not keep
the state per Stub. Also, redesign of profile management is a good time to add support for
TAG_ALTERNATE_IIOP (multiple endpoints per profile).
Bala is familiar with profile management code, and has agreed to act as a consultant/guide when somebody tackles this item.
When an object is forwarded, a new set of profiles is received, and they can potentially include different client-exposed policies. Currently, we don't handle this case, i.e., the set of client-exposed policies from the object's original IOR is used for its complete lifetime. This item is related to the profile management issue.
Selection of endpoints for invocations in TAO is strategized, with strategies for different policy combinations located in Invocation_Endpoint_Selectors.* Bala may want to make FT-based endpoint selection one of the available strategies. (Currently it's not part of the endpoint selectors framework.)
Speaking of ORB debug output, there is not much consistency about it in TAO: not in the use of ORB debug levels, not in the style and detail of debug messages. It is probably a good idea to come up with a short list of guidelines for debugging messages - this would make the output more useful (if the guidelines are followed, of course ;-) )
Last modified: $Date$