diff options
Diffstat (limited to 'TAO/docs/rtcorba/issues.html')
| -rw-r--r-- | TAO/docs/rtcorba/issues.html | 111 |
1 files changed, 23 insertions, 88 deletions
diff --git a/TAO/docs/rtcorba/issues.html b/TAO/docs/rtcorba/issues.html index 9ba90e9ea54..b25841bf1dd 100644 --- a/TAO/docs/rtcorba/issues.html +++ b/TAO/docs/rtcorba/issues.html @@ -11,73 +11,52 @@ <h2><a name="top">Known Issues and TO-DO Items</a></h2> <p>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 <a href="http://ace.cs.wustl.edu/bugzilla/query.cgi">query -Bugzilla</a> for RTCORBA entries. (At the time of writing, there was one RTCORBA -Bugzilla entry, <a href="http://ace.cs.wustl.edu/bugzilla/show_bug.cgi?id=737">#737</a>.)</p> +items. The list does not include any of the reports from the bug tracking +system, so be sureto <a href="http://ace.cs.wustl.edu/bugzilla/query.cgi">query +Bugzilla</a> for RTCORBA entries. </p> <ol> - <li><a href="#1">Standard PolicyTypes for RTCORBA policies</a></li> <li><a href="#7">Integrating protocol policies with the Pluggable Protocols framework</a></li> - <li><a href="#9">Separating RTCORBA features into a library</a></li> <li><a href="#10">Integrating Implementation Repository with RTCORBA and PP</a></li> <li><a href="#12">Priority Banded Connections interoperability issues</a></li> - <li><a href="#4">Removing TAO::Client_Priority_Policy</a></li> - <li><a href="#13">Priority issues in SCHED_OTHER class on Solaris</a> - </li> <li><a href="#2">Removing dependencies on ORB debug output from RTCORBA tests</a></li> <li><a href="#14">Adding RTCORBA examples</a></li> <li><a href="#5">Improving management of Private Connections</a></li> <li><a href="#6">Redesigning profile management to satisfy new requirements and to provide full - support for location forwarding</a> </li> + support for location forwarding</a></li> <li><a href="#11">Location forwarding with client-exposed policies</a></li> <li><a href="#8">Moving FT endpoint selection into the endpoint selectors framework</a></li> <li><a href="#3">Introducing guidelines for debug output in TAO</a><br> </li> </ol> <hr> -<h4><a name="1">Standard PolicyTypes for RTCORBA policies</a></h4> -<p><a href="http://cgi.omg.org/cgi-bin/doc?ptc/99-05-03">ptc/99-05-03</a> 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. </p> - -<p>Files to update: -orbconf.h and RTCORBA.*</p> - -<p><a href="#top">[back]</a></p> - -<hr> <h4><a name="7">Integrating protocol policies with the Pluggable Protocols framework</a></h4> <p><i>RTCORBA::ServerProtocolPolicy</i> and <i>RTCORBA::ClientProtocolPolicy</i> 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 +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 disabled, better +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.</p> <ol> <li>Integrate protocol policies with PP framework. Make concrete <i> Protocol_Factories</i> responsible for creating corresponding <i>ProtocolProperties</i> with default and user-specified -values (rather than having the knowledge about concrete <i>ProtocolProperties </i>embedded in the ORB). +values (rather than having the knowledge about concrete <i>ProtocolProperties </i>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. <br> - <br> - Places to update: RT_Policy_i.*, RTCORBA.*, pluggable protocols files, - ORB_Core::set_default_policies, RTCORBA tests.<br> +each protocol.<br> </li> - <li>Make protocol policies available even when RTCORBA is not enabled. Once + <li>Make protocol policies available even when RTCORBA is not used. Once this is done, remove (or deprecate) <i>-ORBSndSock</i>, <i>-ORBRcvSock</i>, and <i>-ORBNodelay</i> ORB options.<br> </li> <li>Add support for <i>TCPProtocolProperties::keep_alive</i> and <i>TCPProtocolProperties::dont_route</i> - in IIOP.<br> - </li> - <li>Add support for protocol properties configuration in SHMIOP. (SHMIOP + in IIOP.<br> </li> + <li>Add support for protocol properties configuration in SHMIOP. (SHMIOP properties are defined in <i>RTCORBA::SharedMemoryProtocolProperties</i>, but are currently not supported in the protocol implementation.)</li> </ol> @@ -85,17 +64,10 @@ and <i>-ORBNodelay</i> ORB options.<br> <p><a href="#top">[back]</a></p> <hr> -<h4><a name="9">Separating RTCORBA features into a library</a></h4> -<p>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.</p> - -<p><a href="#top">[back]</a></p> - -<hr> <h4><a name="10">Integrating Implementation Repository with RTCORBA and PP</a></h4> <p>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 +one server. Once RTCORBA implementation is complete, we should look into redesign of Implementation Repository.</p> <p><a href="#top">[back]</a></p> @@ -145,7 +117,7 @@ Banded Connections by: <li>modifying server to move a connection to the appropriate reactor once it receives <CODE> bind_priority_band </CODE>request and/or - <CODE> RTCorbaPriorityRange </CODE> service context </li> + <CODE> RTCorbaPriorityRange </CODE> service context</li> <li>modifying client to store and look up connections based on address + priority range rather than just based on address @@ -154,43 +126,6 @@ Banded Connections by: <p><a href="#top">[back]</a></p> <hr> -<h4><a name="4">Removing TAO::Client_Priority_Policy</a></h4> -<p>TAO-proprietary <i> Client_Priority_Policy</i> 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 <i> Client_Protocol_Policy</i> and all related code from TAO before the next -release. </p> - -<p>Involved files: TAO.pidl, Client_Priority_Policy.* Policy_Manager.*, -orbconf.h, Stub.*, Invocation_Endpoint_Selectors.*, ORB_Core.*, tests/Endpoint_per_Priority/*</p> - -<p><a href="#top">[back]</a></p> - -<hr> -<h4><a name="13">Priority issues in SCHED_OTHER class on Solaris</a></h4> -<p>In RTCORBA tests involving priorities, we are using <CODE>SCHED_OTHER </CODE> scheduling class rather than <CODE>SCHED_FIFO </CODE>. -This is for convenience: no super-user -privileges are -required, and we can run the tests in our daily builds.</p> -<p>On Solaris, the following code</p> -<pre>int max_priority = ACE_Sched_Params::priority_max (ACE_SCHED_OTHER); -int min_priority = ACE_Sched_Params::priority_min (ACE_SCHED_OTHER);</pre> -<p>produces <i> min_priority</i> of -60 and <i> max_priority</i> of 60. With <i>Direct</i> 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>i.e.</i>, native priority -60, the call fails. In general, calls with negative -native priorities fail, and calls with positive native priorities succeed.</p> -<p>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.</p> -<p>I am not sure what the proper resolution is, <i>e.g.</i>, whether this is -ok/correct and just needs to be documented, or whether we should be using some -methods different from <CODE> ACE_Sched_Params::priority_max </CODE>and <CODE>priority_min </CODE>to obtain -the valid priority range for a given OS/scheduling class, etc. We need to check -this out.</p> - -<p><a href="#top">[back]</a></p> - -<hr> <h4><a name="2">Removing dependencies on ORB debug output from RTCORBA tests</a></h4> @@ -209,9 +144,9 @@ should look into this.</p> <hr> <h4><a name="14">Adding RTCORBA examples</a></h4> <p>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. </p> +examples. Use case-driven examples illustrating how certain features help +satisfy various requirements. Examples that would help users understand +when to use various features.</p> <p><a href="#top">[back]</a></p> @@ -229,7 +164,7 @@ want to have it controlled by an option.</p> to provide full support for location forwarding</a></h4> <p>Current client profile management code needs to change for the -following reasons: </p> +following reasons:</p> <ol> <li>Original design assumed that all threads using the same object reference would want to use the same profile for making an invocation. Hence, certain @@ -240,13 +175,13 @@ following reasons: </p> 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 <i>Stub</i>. </li> + the state per <i>Stub</i>.</li> <li>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. </li> + level deep. And with certain policy configurations, location + forwarding is not supported at all.</li> <li>Current interfaces are very polluted: many tiny functions with similar names calling into each other, comments in <i> .h</i> files outdated, comments in - <i> .cpp</i> files mostly absent. </li> + <i> .cpp</i> files mostly absent.</li> <li>Lack of thorough test suite.</li> </ol> <p>Also, redesign of profile management is a good time to add support for @@ -270,7 +205,7 @@ management</a> issue.</p> <h4><a name="8">Moving FT endpoint selection into the endpoint selector framework</a></h4> <p>Selection of endpoints for invocations in TAO is strategized, with strategies for -different policy combinations located in <i>Invocation_Endpoint_Selectors.*</i> +different policy combinations located in <i>Invocation_Endpoint_Selectors.*</i> Bala may want to make FT-based endpoint selection one of the available strategies. (Currently it's not part of the endpoint selectors framework.)</p> @@ -291,6 +226,6 @@ the guidelines are followed, of course ;-) )</p> <i> <p>Last modified: $Date$ </i></p> -<p> </p> +<p></p> </body> </html> |