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 sureto query Bugzilla for RTCORBA entries.
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 with RTCORBA. 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 not used, better integrate them with the Pluggable Protocols framework, and provide a number of other enhancements.
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.
Section 4.12.2 (Binding of Priority Banded Connection) of the RT-CORBA
spec talks about the _bind_priority_band implicit
operation. Clearly, this operation is not completely defined and
neither is the reply to this implicit operation. Therefore, it is
almost impossible to get interoperability between RT-ORBs with respect
to this operation.
Even if we make assumptions about the _bind_priority_band
implicit operation and its reply, it leads to an architecture where
there is unnecessary jitter and unpredictability because the
connection needs to be moved from the Reactor associated with the
Acceptor to the Reactor associated with correct priority. This is
either done with the _bind_priority_band method or with
the first request.
Because of the above mentioned issues, 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.)
Once the semantics of the _bind_priority_band operation
have been fully described by the specification or if the application
can deal with the unpredictability of the first request, and TAO can
be redesigned to handle the additional complexity of connection
movement between the Reactors, we can change the behavior of Priority
Banded Connections by:
bind_priority_band
operation and RTCorbaPriorityRange service context
during Object::_validate_connection() bind_priority_band request and/or
RTCorbaPriorityRange service contextSome 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 ;-) )