diff options
author | schmidt <douglascraigschmidt@users.noreply.github.com> | 2004-12-31 20:09:35 +0000 |
---|---|---|
committer | schmidt <douglascraigschmidt@users.noreply.github.com> | 2004-12-31 20:09:35 +0000 |
commit | 8b3493c8aa1dbdfb19f80f1d00e9f89720058a76 (patch) | |
tree | 39b0aca8cb929e2315b50708f7185f41a93bd68e /TAO/docs/Options.html | |
parent | b287261d726cb3362b9a1031e7e2c31f243f7ea3 (diff) | |
download | ATCD-8b3493c8aa1dbdfb19f80f1d00e9f89720058a76.tar.gz |
ChangeLogTag:Thu Dec 30 13:21:37 2004 Chris Cleeland <cleeland@ociweb.com>
Diffstat (limited to 'TAO/docs/Options.html')
-rw-r--r-- | TAO/docs/Options.html | 100 |
1 files changed, 49 insertions, 51 deletions
diff --git a/TAO/docs/Options.html b/TAO/docs/Options.html index c9310ec1519..2876d2a416e 100644 --- a/TAO/docs/Options.html +++ b/TAO/docs/Options.html @@ -92,7 +92,7 @@ high-performance applications. <li> <b>Command-line options</b> are passed to the ORB initialization factory method, <code>CORBA::ORB_init()</code>, by an application -using the standard <i>argc, argv</i> tuple passed to the application's +using the standard <i>argc/argv</i> tuple passed to the application's <code>main()</code>. Most of the options that can be exercised through environment variables can also be manipulated through command-line @@ -108,13 +108,7 @@ configurator file, whose default file name is <code>svc.conf</code>. The service configurator is opened and processed by the ORB in <code>CORBA::ORB_init()</code>. The service configurator processing is done after all the command-line options -have been<!-- Bala, should this be "processed" or just "parsed"? -There could be a different --> -parsed. - <p><!-- It should be just "parsed". The options from the command lines -<!-- are just parsed in ORB_init () and stored for later use --> -<!-- For the service configurator it is tricky. To be on the safer -<!-- side I would say "processed". --></p> +have been parsed. </li> </ul> <p></p> @@ -377,7 +371,7 @@ default is used.</td> the ORB does not generate the OMG standardized profile components, such as the ORB type and code sets. Notice that the presence of this components is optional in GIOP 1.1 The default value is controlled by a -compile-time flag (check orbconf.h).</td> +compile-time flag defined in <CODE>orbconf.h</CODE>.</td> </tr> <tr> <td><code>-ORBSingleReadOptimization</code> <em>boolean (0|1)</em></td> @@ -390,7 +384,7 @@ the ORB will do a read of size <code>TAO_MAXBUFSIZE</code>, hoping to read the entire request. If more than one request is read they will be queued up for processing later. <p> This option defaults to <code>1</code> because it can -provide better performance. However, in the case of RT-CORBA, this +provide better performance. In the case of Real-time CORBA, however, this option should be set to <code>0</code>. Consider the following scenario: (1) two requests are read from one socket, (2) the additional request is queued, and (3) the ORB uses its Reactor's notification @@ -405,13 +399,13 @@ preferences over normal I/O, thereby causing priority inversion.</p> <td><code>-ORBDisableRTCollocation</code> <em>boolean (0|1)</em></td> <td><a name="-ORBDisableRTCollocation"></a>This option controls whether the application wants to use or discard - RT collocation decisions made by the RT ORB. A value of true - disables RT collocation decisions and falls back on the default - collocation decisions implemented in the default ORB. This is - very useful for applications using the RT ORB and doesn't want + RT collocation decisions made by the RT ORB. A value of + <CODE>1</CODE> (true) disables RT collocation decisions and falls back on the default + collocation decisions implemented in the default ORB, which is + useful for applications using the RT ORB and doesn't want to use the RT collocation decisions but fallback on the default decisions for better performance. The default value is - <code>0</code>. </td> + <code>0</code> (false). </td> </tr> </tbody> </table> @@ -436,7 +430,7 @@ selection within a TAO application. <td><code>-ORBDefaultInitRef</code> <em>IOR prefix</em></td> <td><a name="-ORBDefaultInitRef"></a>This argument allows resolution of initial references not explicitly specified with --ORBInitRef. It requires a URL prefix that, after appending a slash '/' +<CODE>-ORBInitRef</CODE>. It requires a URL prefix that, after appending a slash '/' ('|' for the UIOP pluggable protocol) and a simple object key, forms a new URL to identify an initial object reference. The URL prefix format currently supported is based on the standard <code>corbaloc</code> @@ -478,8 +472,8 @@ since domain names are the standard address notation for IORs.</td> <td><code>-ORBEnforcePreferredInterfaces</code> <em>Yes/No</em></td> <td><a name="-ORBEnforcePreferredInterfaces"></a> This option - specifies whether -ORBPreferredInterfaces option needs to be - enforced. The option is supposed to help with the following + specifies whether <CODE>-ORBPreferredInterfaces</CODE> option + needs to be enforced. The option is supposed to help with the following usecase. It is possible that under some situations the preferred local network may not have a route to the target host/interface. The ORB can do one of the following. The ORB @@ -496,10 +490,10 @@ since domain names are the standard address notation for IORs.</td> <td><code>-ORBListenEndpoints</code> <em>endpoint</em></td> <td><a name="-ORBListenEndpoints"></a> This option was introduced with the CORBA <a - href="http://cgi.omg.org/docs/orbos/01-01-04.pdf"> ORT </a> - (Object Reference Template) specification. It instructs a + href="http://cgi.omg.org/docs/orbos/01-01-04.pdf">Object + Reference Template</A> (ORT) specification. It instructs a server ORB to listen for requests on the interface specified - by <code>endpoint</code>. When used with RT-CORBA, the option + by <code>endpoint</code>. When used with Real-time CORBA, the option specifies the endpoints that the default thread pool listens to. TAO endpoints are specified using a URL style format. An endpoint has the form: @@ -512,7 +506,7 @@ since domain names are the standard address notation for IORs.</td> Sets of endpoints may be specified using multiple <code>-ORBListenEndpoints</code> options or by delimiting - endpoints with a semi-colon (;). For example, + endpoints with a semi-colon (;). For example, <blockquote><code>-ORBListenEndpoints iiop://localhost:9999 -ORBListenEndpoints uiop:///tmp/mylocalsock -ORBListenEndpoints shmiop://10002 </code></blockquote> is @@ -546,8 +540,8 @@ since domain names are the standard address notation for IORs.</td> <em>thread-pool-id:thread-lane-id endpoint</em></td> <td><a name="-ORBLaneListenEndpoints"></a> This option allows the user to specify endpoints for thread pools and lanes. This - option is only meaningful when used with RT-CORBA and only - makes sense when the thread pools and lanes are created in the + option is only meaningful when used with Real-time CORBA and + only makes sense when the thread pools and lanes are created in the same order across server incarnations. See <a href="#-ORBListenEndpoints"><code>-ORBListenEndPoints</code></a> option on how to specify endpoints. An example is: @@ -650,9 +644,9 @@ provided for specific application requirements. <tr> <td><code>-ORBId</code> <em>orb_name</em></td> <td><a name="-ORBId"></a>This option allows the name of an ORB -to be set to <code>orb_name</code>. The ORBId will be passed to the -ORB_init() method to differentiate coexisting ORBs (when there are more -than one ORBs).</td> +to be set to <code>orb_name</code>. The <CODE>ORBId</CODE> will be +passed to the <CODE>CORBA::ORB_init()</CODE> method to differentiate +coexisting ORBs (when there is more than one ORB).</td> </tr> <tr> <td><code>-ORBServerId</code> <em>server_id</em></td> @@ -844,14 +838,16 @@ new IOR formats </a>using this option. </td> <td><code>-ORBConnectionPurgingStrategy</code> <em>type</em></td> <td><a name="-ORBConnectionPurgingStrategy"></a>Opened connections are added to the transport cache so they can be reused. -However, if a process continues to run and these connections are not -reused, the cache will continue to grow. Therefore, before each new -connection, the cache is checked and purged if it has reached the limit -specified by the -ORBConnectionCacheMax option or the system default if -that option was not used. The possible values for type are lru, lfu, -fifo and null. The default is LRU (Least Recently Used). The others LFU -(Least Frequently Used), FIFO (First In First Out), and null (No -connections are purged) are contained within the TAO Strategies +If a process continues to run and these connections are not reused, +however, the cache will continue to grow. Before each new connection, +therefore, the cache is checked and purged if it has reached the limit +specified by the <CODE>-ORBConnectionCacheMax</CODE> option or the +system default if that option was not used. The possible values for +type are <CODE>lru</CODE>, <CODE>lfu</CODE>, <CODE>fifo</CODE>, and +<CODE>null</CODE>. The default is <CODE>lru</CODE> (least recently +used). The other options are <CODE>lfu</CODE> (least frequently used), +<CODE>fifo</CODE> (first in first out), and <CODE>null</CODE> (no +connections are purged) and are contained within the TAO Strategies library. </td> </tr> <tr> @@ -859,7 +855,7 @@ library. </td> <td><a name="-ORBConnectionCacheMax"></a>The transport cache will grow to a maximum of the specified limit. The default is system dependent, but can be overridden at compile-time by defining the -preprocessor macro TAO_CONNECTION_CACHE_MAXIMUM. </td> +preprocessor macro <CODE>TAO_CONNECTION_CACHE_MAXIMUM</CODE>. </td> </tr> <tr> <td><code>-ORBMuxedConnectionMax</code> <em>number</em></td> @@ -1012,23 +1008,25 @@ default.</td> <tr> <td><code>-ORBReactorThreadQueue</code> <em>which</em></td> <td><a name="-ORBReactorThreadQueue"></a>Applies only to the -ACE_TP_Reactor, i.e., when <code>-ORBReactorType</code> = <code>tp</code>, -and specifies the order, last-in-first-out (<em>which</em> = <code>LIFO</code>), -the default, or first-in-first-out (<em>which</em> = <code>FIFO</code>), -in which waiting threads are selected to run by the -ACE_Select_Reactor_Token. </td> +<CODE>ACE_TP_Reactor</CODE>, i.e., when <code>-ORBReactorType</code> = +<code>tp</code>, and specifies the order, last-in-first-out +(<em>which</em> = <code>LIFO</code>), the default, or +first-in-first-out (<em>which</em> = <code>FIFO</code>), in which +waiting threads are selected to run by the +<CODE>ACE_Select_Reactor_Token</CODE>. </td> </tr> <tr> <td><code>-ORBInputCDRAllocator</code> <em>which</em></td> - <td><a name="-ORBInputCDRAllocator"></a>Specify whether the ORB -uses locked (<em>which</em> = <code>thread</code>) or lock-free (<em>which</em> -= <code>null</code>) allocators for the incoming CDR buffers. Though <code>null</code> -should give the optimal performance; we made the default <code>thread</code>. -TAO optimizations for octet sequences will not work in all cases when -the allocator does not have locks (for example if the octet sequences -are part of a return value). Using locked allocators also allows the -users to take advantage of the TAO octet sequence extensions to -preserve the buffer after the upcall. </td> + <td><a name="-ORBInputCDRAllocator"></a>Specify whether the +ORB uses locked (<em>which</em> = <code>thread</code>) or lock-free +(<em>which</em> = <code>null</code>) allocators for the incoming CDR +buffers. Though <code>null</code> should give the optimal performance; +we made the default <code>thread</code>. TAO optimizations for octet +sequences will not work in all cases when the allocator does not have +locks (for example if the octet sequences are part of a return +value). Using locked allocators also allows the users to take +advantage of the TAO octet sequence extensions to preserve the buffer +after the upcall. </td> </tr> <tr> <td><code>-ORBAMHResponseHandlerAllocator</code> <em>which</em></td> @@ -1288,7 +1286,7 @@ one way calls. This strategy can also be used in an application that is both a client and a server if the server side is handled by a separate thread and the client threads are "pure" clients. </p> <p> - MT_NOUPCALL means use a client connection handler that + <CODE>MT_NOUPCALL</CODE> means use a client connection handler that participates in the leader-follower model like MT, but, like RW, does not allow handling of nested upcalls within the waiting thread. Note that with this strategy it is possible |