Implementation Issues and Known Bugs

### Known Issues and TO-DO Items

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.

1. Integrating protocol policies with the Pluggable Protocols framework
2. Integrating Implementation Repository with RTCORBA and PP
3. Priority Banded Connections interoperability issues
4. Removing dependencies on ORB debug output from RTCORBA tests
5. Adding RTCORBA examples
6. Improving management of Private Connections
7. Redesigning profile management to satisfy new requirements and to provide full support for location forwarding
8. Location forwarding with client-exposed policies
9. Moving FT endpoint selection into the endpoint selectors framework
10. Introducing guidelines for debug output in TAO

#### Integrating protocol policies with the Pluggable Protocols framework

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.

1. Integrate protocol policies with PP framework. Make concrete Protocol_Factories responsible for creating corresponding ProtocolProperties with default and user-specified values (rather than having the knowledge about concrete ProtocolProperties embedded in the ORB). This will enable the protocol policies to be used to configure any pluggable protocols without having to modify the ORB code for each protocol.
2. Make protocol policies available even when RTCORBA is not used. Once this is done, remove (or deprecate) -ORBSndSock, -ORBRcvSock, and -ORBNodelay ORB options.
3. Add support for TCPProtocolProperties::keep_alive and TCPProtocolProperties::dont_route in IIOP.
4. Add support for protocol properties configuration in SHMIOP. (SHMIOP properties are defined in RTCORBA::SharedMemoryProtocolProperties, but are currently not supported in the protocol implementation.)

[back]

#### Integrating Implementation Repository with RTCORBA and PP

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.

[back]

#### Priority Banded Connections interoperability issues

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:

1. modifying client to use `bind_priority_band` operation and `RTCorbaPriorityRange` service context during `Object::_validate_connection()`
2. modifying server to move a connection to the appropriate reactor once it receives `bind_priority_band` request and/or `RTCorbaPriorityRange` service context
3. modifying client to store and look up connections based on address + priority range rather than just based on address alone

[back]

#### Removing dependencies on ORB debug output from RTCORBA tests

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.

[back]

#### Adding RTCORBA examples

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.

[back]

#### Improving management of Private Connections

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.

[back]

#### Redesigning profile management to satisfy new requirements and to provide full support for location forwarding

Current client profile management code needs to change for the following reasons:

1. Original design assumed that all threads using the same object reference would want to use the same profile for making an invocation. Hence, certain state, i.e., `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.
2. Current design does not properly support location forwarding more than one level deep. And with certain policy configurations, location forwarding is not supported at all.
3. Current interfaces are very polluted: many tiny functions with similar names calling into each other, comments in .h files outdated, comments in .cpp files mostly absent.
4. Lack of thorough test suite.

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.

[back]

#### Location forwarding with client-exposed policies

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.

[back]

#### Moving FT endpoint selection into the endpoint selector framework

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

[back]

#### Introducing guidelines for debug output in TAO

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

[back]

Last modified: 2002/08/02 22:42:34