diff options
Diffstat (limited to 'TAO/docs/Options.html')
| -rw-r--r-- | TAO/docs/Options.html | 852 |
1 files changed, 0 insertions, 852 deletions
diff --git a/TAO/docs/Options.html b/TAO/docs/Options.html deleted file mode 100644 index 48bd199926c..00000000000 --- a/TAO/docs/Options.html +++ /dev/null @@ -1,852 +0,0 @@ - - -<HTML> -<HEAD> -<!-- $Id$ --> -<META NAME="GENERATOR" CONTENT="Adobe PageMill 2.0 Mac"> -<TITLE>Options for TAO Components</TITLE> -</HEAD> - -<BODY text = "#000000" -link="#000fff" -vlink="#ff0f0f" -bgcolor="#ffffff"> - -<HR><P> -<H3 ALIGN=CENTER>Options for TAO Components</H3> - -<H3>Overview</H3> -<blockquote> - -<p>TAO can be configured in several ways. Certain components in TAO, -such as the ORB Core or Object Adapter, can be tuned by users by -providing value for options or environment variables to them. These -options are commonly specified as (1) environment variables or (2) -strings passed on the command-line. Command-line options and -environment variables to control global ORB features, such as the IOR -format or ORB's bootstrapping methods. They are generally passed to -component initialization methods for consumption. <P> - -In addition, options in <code>svc.conf</code> file provide a mechanism -to fine-tune internal components in TAO that are specific to -particular configurations. If your program use-cases have particular -characteristics, you can use the <code>svc.conf</code> file to -customize your programs and use various optimization provided by TAO . -However, a <code>svc.conf</code> file is not required to run TAO -programs. </p> - -<P><EM>Programmer's Note:</EM> the internal structure for options is -the traditional <CODE>argc</CODE>/<CODE>argv</CODE> vector of strings -style popularized by C and Unix. By convention, an initialization -method will consume, <EM>i.e.</EM>, remove from the vector, any -options that it recognizes.</P> </blockquote> - -<HR><P> -<H3><A NAME="ev">Environment Variables</A></H3> - -The following environment variables are supported by TAO: - -<BLOCKQUOTE> -<P><TABLE BORDER="2" CELLSPACING="2" CELLPADDING="0" > - <TR> - <TH>Environment Variable</TH> - <TH>Description</TH> - </TR> - <TR> - <TD><CODE>NameServiceIOR</CODE> <EM>which</EM></TD> - <TD> - Specifies which IOR the Naming Service is listening on. - </TD> - </TR> - <TR> - <TD><CODE>NameServicePort</CODE> <EM>which</EM></TD> - <TD> - Specifies which port the Naming Service is listening on for multicast - requests. - </TD> - </TR> - <TR> - <TD><CODE>TradingServiceIOR</CODE> <EM>which</EM></TD> - <TD> - Specifies which IOR the Trading Service is listening on. - </TD> - </TR> - <TR> - <TD><CODE>TradingServicePort</CODE> <EM>which</EM></TD> - <TD> - Specifies which port the Trading Service is listening on for multicast - requests. - </TD> - </TR> - <TR> - <TD><CODE>ImplRepoServiceIOR</CODE> <EM>which</EM></TD> - <TD> - Specifies the IOR of an Implementation Repository. - </TD> - </TR> - <TR> - <TD><CODE>ImplRepoServicePort</CODE> <EM>which</EM></TD> - <TD> - Specifies which port the Implementation Repository is listening on for - multicast requests. - </TD> - </TR> -</TABLE> -</P> -</BLOCKQUOTE> - -<HR><P> - -<H3>Types of Options</H3> - -<blockquote> -<P>The following components can be tuned via options:</P> - -<UL> - <LI><A HREF="#ORB"><CODE>CORBA::ORB</CODE></A> - <LI><A HREF="#ResourceFactory"><CODE>TAO_Resource_Factory</CODE></A> - <LI><A HREF="#DefaultServer"><CODE>TAO_Default_Server_Strategy_Factory</CODE></A> - <LI><A HREF="#DefaultClient" TARGET="_top"><CODE>TAO_Default_Client_Strategy_Factory</CODE></A> -</UL> - -Typically, CORBA::ORB options are set via command line parameters that -are eventually passed to CORBA::ORB_init (), while the rest of the -options are set via the service configurator (svc.conf) file. - -</blockquote> - -<blockquote> -<H3><CODE>CORBA::ORB</CODE><A NAME="ORB"></A></H3> - -<p><em>Note:</em> <code>-ORBGlobalCollocation</code> flag has been -merged with <a href="#-ORBCollocation"><code>-ORBCollocation</code></a>. - -<blockquote> -<P><TABLE BORDER="2" CELLSPACING="2" CELLPADDING= "0"> - <TR> - <TH>Option</TH> - <TH>Description</TH> - </TR> - <!-- <TR NAME="ORBsvcconf"> --> - <tr> - <TD><CODE>-ORBSvcConf</CODE> <EM>config file name</EM></TD> - <TD>Specifies the name of the file from which it will read dynamic service configuration - directives <EM>ala</EM> ACE's Service Configurator. By - default, a service configurator-based application will look - for a file named "svc.conf" in the current directory.</TD> - </TR> - <tr> - <TD><CODE>-ORBSvcConfDirective</CODE> <EM>directivestring</EM></TD> - <TD>Specifies a service configuration - directive, which is passed to ACE's Service Configurator.</TD> - </TR> - <TR> - <TD><CODE>-ORBDaemon</CODE></TD> - <TD>Specifies that the ORB should <I>daemonize</I> itself.</TD> - </TR> - <TR> - <TD><CODE>-ORBDebug</CODE></TD> - <TD>Turns on the output of debugging messages within ACE's Service Configurator - componentry.</TD> - </TR> - <TR> - <TD><CODE>-ORBDebugLevel</CODE> <EM>level</EM></TD> - <TD>Control the level of debugging in the ORB. Higher number produce - more output (try 10). - </TD> - </TR> - <TR> - <TD><CODE>-ORBEndpoint</CODE> <EM>endpoint</EM></TD> - <TD><a name="-ORBEndpoint"></a>Tells the ORB to listen for requests on the - interface specified by <I><EM>endpoint</EM></I>. Endpoints are - specified using a URL style format. An endpoint has the form: - <blockquote><CODE> - protocol://V.v@addr1,...,W.w@addrN - </CODE></blockquote> - where <CODE>V.v</CODE> and <CODE>W.w</CODE> are optional protcol versions for - each address. An example of an IIOP endpoint is: - <blockquote><CODE> - iiop://<I><EM>hostname</EM></I>:<I><EM>port</EM></I> - </CODE></blockquote> - Sets of endpoints may be specified using multiple <CODE>-ORBEndpoint</CODE> - options or by delimiting endpoints with a semi-colon (;). For example, - <blockquote><CODE> - -ORBEndpoint iiop://localhost:9999 -ORBEndpoint uiop:///tmp/mylocalsock - </CODE></blockquote> - is equivalent to: - <blockquote><CODE> - -ORBEndpoint 'iiop://localhost:9999;uiop:///tmp/mylocalsock' - </CODE></blockquote> - Notice the single quotes (') in the latter option specification. Single - quotes are needed to prevent the shell from interpreting text after the - semi-colon as another command to run.<P> - If an endpoint is specified without an <CODE>addr</CODE> such as the following: - <blockquote><CODE> - -ORBEndpoint uiop:// - </CODE></blockquote> - then a default endpoint will be created for the specified protocol. - <P> - This is a server side option. - </TD> - </TR> - - <TR> - - <TD><CODE>-ORBHost</CODE> <EM>hostname</EM></TD> - <TD><a name="-ORBHost"></a>Tells the ORB to listen for requests on the - interface associated with the host named - <I><EM>hostname</EM></I>. This option is valid only for IIOP endpoints.<BR> - <STRONG>NOTE:</STRONG> This option has been superseded by the - <CODE>-ORBEndpoint</CODE> option. It will not be supported in the - future.</TD> - </TR> - - <TR> - - <TD><CODE>-ORBPort</CODE> <EM>portspec</EM></TD> - <TD>Tells the ORB to - listen for requests on the port specified by - <I><EM>portspec</EM></I>. If not specified, the OS gets to choose a - random empty port. This option is valid only for IIOP endpoints.<BR> - <STRONG>NOTE:</STRONG> This option has been superseded by the - <CODE>-ORBEndpoint</CODE> option. It will not be supported in the - future.</TD> - - </TR> - - <TR> - <TD><CODE>-ORBObjRefStyle</CODE> <EM>which</EM></TD> - <TD>Specifies the user-visible style of object references. The range of values - is <CODE>IOR</CODE> (default), which is the traditional nonsensical object reference, - or <CODE>URL</CODE>, which looks more like a URL.</TD> - </TR> - <TR> - <TD><CODE>-ORBRcvSock</CODE> <EM>receive buffer size</EM></TD> - <TD><A NAME="-ORBRcvSock"></a>Specify the size of the socket receive buffer as a positive, non-zero integer. - If not specified, the ACE_DEFAULT_MAX_SOCKET_BUFSIZ default is used.</TD> - </TR> - <TR> - <TD><CODE>-ORBSndSock</CODE> <EM>send buffer size</EM></TD> - <TD><A NAME="-ORBSndSock"></a>Specify the size of the socket send buffer as a positive, non-zero integer. - If not specified, the ACE_DEFAULT_MAX_SOCKET_BUFSIZ default is used.</TD> - </TR> - <TR> - <TD><CODE>-ORBNodelay</CODE> <EM>boolean (0|1)</EM></TD> - <TD><A NAME="-ORBNodelay"></a>Enable or disable the TCP_NODELAY - option. By default, TCP_NODELAY is enabled.</TD> - </TR> - <TR> - <TD><CODE>-ORBNameServicePort</CODE> <EM>portspec</EM></TD> - <TD>Specifies which port the Naming Service is listening on for - multicast requests. By default, - TAO_DEFAULT_NAME_SERVICE_REQUEST_PORT, which is 10013 is used.</TD> - </TR> - <TR> - <TD><CODE>-ORBNameServiceIOR</CODE> <EM>ior</EM></TD> - <TD>Specifies the IOR for the Naming Service. Note, this option - is deprecated since its functionality can be achieved with the - standard <CODE>-ORBInitRef</CODE> option defined by the <A - HREF="INS.html">Interoperable Naming Service</A>. </TD> - </TR> - <TR> - <TD><CODE>-ORBTradingServicePort</CODE> <EM>portspec</EM></TD> - <TD>Specifies to which port the Trading Service is listening on for - multicast requests. By default, - TAO_DEFAULT_TRADING_SERVICE_REQUEST_PORT which is 10016 is used.</TD> - </TR> - <TR> - <TD><CODE>-ORBTradingServiceIOR</CODE> <EM>ior</EM></TD> - <TD>Specifies the IOR for the Trading Service. Note, this option - is deprecated since its functionality can be achieved with the - standard <CODE>-ORBInitRef</CODE> option defined by the <A - HREF="INS.html">Interoperable Naming Service</A>.</TD> - </TR> - <TR> - <TD><CODE>-ORBImplRepoServicePort</CODE> <EM>portspec</EM></TD> - <TD>Specifies to which port the Implementation Repository is listening on for - multicast requests. By default, - TAO_DEFAULT_IMPLREPO_SERVER_REQUEST_PORT which is 10018 is to - be used.</TD> - </TR> - <TR> - <TD><CODE>-ORBImplRepoServiceIOR</CODE> <EM>ior</EM></TD> - <TD>Specifies the IOR for the Implementation Repository. Note, this option - is deprecated since its functionality can be achieved with the - standard <CODE>-ORBInitRef</CODE> option defined by the <A - HREF="INS.html">Interoperable Naming Service</A>.</TD> - </TR> - <TR> - <TD><CODE>-ORBMulticastDiscoveryEndpoint</CODE> <EM>end_point</EM></TD> - <TD>Specifies the endpoint that should be used for locating the - Naming Service through multicast. <EM>end_point</EM> is of the - form ip-number:port-number (e.g., "tango.cs.wustl.edu:1234" or - "128.252.166.57:1234"). If there is no ':' in the end_point it - is assumed to be a port number, with the IP address being INADDR_ANY. - </TR> - <TR> - <TD><CODE>-ORBCollocation</CODE> <EM>yes/global/per-orb/no</EM></TD> - <TD><a name="-ORBCollocation"></a>Specifies the use of collocation - object optimization. If <em>global</em> or <em>yes</em> is - specified, objects in the same process will be treated as collocated. - If <em>per-orb</em> is specified, only objects in the same ORB are - treated as collocated. When <em>no</em> is specified, no objects are - treated as collocated. Default is global.</TD> - </TR> - <TR> - <TD> - <CODE>-ORBCollocationStrategy</CODE> <EM>thru_poa/direct</EM> - </TD> - <TD> - Specifies what kind of collocated object to use. If the - <em>thru_poa</em> strategy is used, TAO uses the collocation - object implementation that respects POA's current state and - policies. When using the <em>direct</em> strategy, method - invocations on collocated objects become direct calls to servant - without checking POA's status. Default is thru_poa. - </TD> - </TR> - <TR> - <TD><CODE>-ORBPreconnect</CODE> <EM>endpoint</EM></TD> - <TD><A name="-ORBPreconnect"></a>Pre-establishes a blocking connection to - each listed <EM>endpoint</EM>. If a connection cannot be established the - failed preconnection will be ignored and the next preconnection in the list - will be processed. Successful and unsuccessful preconnections will be - displayed if a debugging level greater than or equal to one is specified by - using the <CODE>-ORBDebugLevel</CODE> option. Listing the same combination - multiple times will properly establish multiple connections to that endpoint. - The <CODE>-ORBPreconnect</CODE> option uses the same endpoint format as the - <CODE>-ORBEndpoint</CODE> option. Specifying IIOP endpoints using a comma - delimited list of <EM>host<STRONG>:</STRONG>port</EM> pairs is deprecated - and will not be supported in the future. - <P> - This is a client-side option. - </TD> - </TR> - <TR> - <TD><CODE>-ORBCDRTradeoff</CODE> <EM>maxsize</EM></TD> - <TD><A name="-ORBCDRTradeoff"></a>Control the strategy to tradeoff - between copy vs. no copy marshalling of octet sequences. - If an octet sequence is smaller than <EM>maxsize</EM> and the current - message block contains enough space for it the octet sequence is - copied instead of appended to the CDR stream. By default, - ACE_DEFAULT_CDR_MEMORY_TRADEOFF is used. - </TD> - </TR> - <TR> - <TD><CODE>-ORBSkipServiceConfigOpen</CODE></TD> - <TD><A name="-ORBSkipServiceConfigOpen"></a>Do not call the <code>ACE_Service_Config::open</code> - method, which is necessary if the ORB is being linked dynamically via the ACE Service Configurator - which is not reentrant. Default is </TD> - </TR> - <TR> - <TD><CODE>-ORBGIOPlite</CODE></TD> - <TD><A name="-ORBGIOPlite"></a>Enable a lightweight version of the - GIOP protocol. This protocol removes some of the fields in - the GIOP and the Request header. It only works on - homogeneous environments..</TD> - </TR> - <TR> - <TD><CODE>-ORBDottedDecimalAddresses</CODE> <EM>boolean (0|1)</EM></TD> - <TD><A name="-ORBDottedDecimalAddresses"></a> Use the dotted decimal - notation for addresses. By default domain names are used in IORs.</TD> - </TR> - <TR> - <TD><CODE>-ORBInitRef</CODE> <EM>ObjectId=IOR</EM></TD> - <TD><A name="-ORBInitRef"></a> Allows specification of an arbitrary - object reference for an initial service. The IOR could be in any - one of the following formats : OMG IOR, URL, iioploc (including - uioploc) or file. iioploc is a multiple end-point IOR understood by - the string_to_object () method and used as a boot-strapping - mechanism by the resolve_initial_references () method. The mappings - specified through this argument override the orb-install-time - defaults. The file://<I>pathname</I> interprets the contents of the - <I>pathname</I> file as an object reference in any of the above - formats. - </TD> - </TR> - - <TR> - <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 '/' ('|' for 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 iioploc.</TD> - </TR> - - <TR> - <TD><CODE>-ORBStdProfileComponents</CODE> <EM>boolean (0|1)</EM></TD> - <TD><A name="-ORBStdProfileComponents"></a> If <EM>0</EM> then 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> - </TR> - - <TR> - <TD><CODE>-ORBResources</CODE> <EM>which</EM></TD> - <TD><A name=-ORBResources>Control the use of thread specific resources - in the ORB. - If (<em>which</em> = <code>global</code>) then the - same set of resources are shared by all the threads - that use that ORB. - If (<em>which</em> = <code>tss</code>) then each that - uses that ORB gets its own set of resources. - Currently the resources are limited to the reactor. - </TD> - </TR> - -</TABLE> -</P> -</blockquote> - -<H3><CODE>TAO_Resource_Factory</CODE><A NAME="ResourceFactory"></A></H3> - -<p><em>Note:</em> <code>-ORBReactorLock</code> flag has been superseded by <code>-ORBReactorType</code>. - -<blockquote> -<P><TABLE BORDER="2" CELLSPACING="2" CELLPADDING="0"> - <TR> - <TH>Option</TH> - <TH>Description</TH> - </TR> - <TR> - <TD><CODE>-ORBResources</CODE> <EM>which</EM></TD> - <TD>Specify whether each thread uses a global - (<em>which</em> = <code>global</code>) or a thread-specific - (<em>which</em> = <code>tss</code>) instance for the resources it - returns. The default is <CODE>global </CODE>. - <B>NOTE:</B> This option controls the default value for - the ORB option of the same name.</A>. - </TD> - </TR> - <TR> - <TD><CODE>-ORBReactorType</CODE> <EM>which</EM></TD> - <TD><a name="-ORBReactorType"></a>Specify what kind of reactor does the - ORB use, the options are: - <TABLE BORDER="1" CELLSPACING="2" CELLPADDING="0"> - <TR><TH><em>which</em></TH><TH>Reactor</TH> - </TR> - <TR><TD><CODE>select_mt<CODE></TD><TD>Use the - <CODE>ACE_Select_Reactor</CODE> with the usual - locking mechanism for this platform</TD> - </TR> - <TR><TD><CODE>select_st<CODE></TD><TD>Use the - <CODE>ACE_Select_Reactor</CODE> with null locks - </TD> - </TR> - <TR><TD><CODE>fl<CODE></TD><TD>Use the - <CODE>ACE_FlReactor</CODE> only available if ACE - was compiled with support for the FL toolkit - </TD> - </TR> -</TR> -<TR><TD><CODE>wfmo<CODE></TD> -<TD>Use the - <CODE>ACE_WFMO_Reactor</CODE> only available on - Win32 platforms. -</TD> -</TR> -<TR><TD><CODE>msg_wfmo<CODE></TD><TD>Use the - <CODE>ACE_Msg_WFMO_Reactor</CODE> only available on - Win32 platforms. -</TD> -</TR> -<TR><TD><CODE>tp<CODE></TD><TD>Use the - <CODE>ACE_TP_Reactor</CODE>, a select based - thread-pool reactor. -</TD> -</TR> -</TABLE> -The default is <code>select_mt</code></TD> -</TR> - <TR> - <TD><CODE>-ORBReactorMaskSignals</CODE> <EM>0/1</EM></TD> - <TD>ACE select reactors mask signals during upcalls to the event - handlers. This is only useful if the application is going to - trap those signals and handle them in any way. - Disabling the mask can improve performance by reducing the - number of kernel level locks. - </TD> - </TR> -<TR> - <TD><CODE>-ORBProtocolFactory</CODE> <EM>factory</EM></TD> - <TD><a name="-ORBProtocolFactory"></a> - Specify which pluggable protocol factory to load. By default, - the factories for the IIOP and UIOP protocols (<code>IIOP_Factory</code> - and <code>UIOP_Factory</code>, respectively) are loaded. - <p> - For example, if some protocol called <em><code>Foo</code></em> whose - factory was called <em><code>Foo_Factory</code></em> was available, - then it could be loaded into TAO by specifying - <code>-ORBProtocolFactory Foo_Factory</code> in the service - configurator file. The - <em><code>Foo</code></em> pluggable protocol would then be available - for use. - </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 - if 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>-ORBConnectionCachingStrategy</CODE> <EM>type</EM></TD> - <TD><a name="-ORBConnectionCachingStrategy"></a> - Specify the strategy to use for caching and purging connections. - By default, TAO_CONNECTION_CACHING_STRATEGY is used which has - been set to Least Recently Used (LRU). - For example, for choosing the First In First Out option just add - <code>-ORBConnectionCachingStrategy fifo</code> to the service - configurator file. - </TD> -</TR> -<TR> - <TD><CODE>-ORBPurgePercentage</CODE> <EM>percent</EM></TD> - <TD><a name="-ORBPurgePercentage"></a> - Specify the number of connections to remove form the connection - cache during auto-purging. By default, TAO_PURGE_PERCENT is used - which has been set to 20. - For example, for choosing 75% just add - <code>-ORBPurgePercentage 75</code> to the service configurator - file. - </TD> -</TR> -<TR> - <TD><CODE>-ORBSchedPolicy</CODE> <EM>policy</EM></TD> - <TD><a name="-ORBSchedPolicy"></a> - Specify the scheduling policy used for the priority mapping - computations. - Priority mappings map the CORBA priority range (from 0 to 32767) - into the native OS priority range, but in some operating systems - the range depends on the scheduling policy used. - Using this option the user can set the scheduling policy, valid - values as <B>SCHED_OTHER</B>, <B>SCHED_FIFO</B> and - <B>SCHED_RR</B>, notice that in some operating systems some of - the scheduling policies require super user privileges. - </TD> -</TR> -<TR> - <TD><CODE>-ORBPriorityMapping</CODE> <EM>mapping_type</EM></TD> - <TD><a name="-ORBPriorityMapping"></a> - Select the priority mapping to use. - The default resource factory provide two priority mapping - implementations, <B>linear</B> selects a linear mapping between - the CORBA range of priorities and the native range of - priorities for the selected scheduling policy. - The <B>direct</B> mapping maps the first <B>n</B> CORBA - priorities to the range of native priorities, - where <B>n</B> is the number of native priorities. - In all the operating systems where TAO is supported the range of - CORBA priorities is larger than the native set. - </TD> -</TR> -</TABLE> -</P> -</blockquote> - -<H3><CODE>TAO_Default_Server_Strategy_Factory</CODE><A NAME="DefaultServer"></A></H3> - -<p><em>Note:</em> <code>-ORBDemuxStrategy</code> flag has been changed to <code>-ORBSystemidPolicyDemuxStrategy</code> and <code>-ORBUseridPolicyDemuxStrategy</code>. -<p><em>Note:</em> <code>-ORBTableSize</code> flag has been changed to <code>-ORBActiveObjectMapSize</code>. - -<blockquote> -<P><TABLE BORDER="2" CELLSPACING="2" CELLPADDING="0" > - <TR> - <TH>Option</TH> - <TH>Description</TH> - </TR> - <TR> - - <TD><a name="orb_concurrency"><CODE>-ORBConcurrency</CODE></a> - <EM>which</EM></TD> - <TD>Specify which - concurrency strategy to use. Range of values is <code>reactive</code> - for a purely Reactor-driven concurrency strategy or - <code>thread-per-connection</code> for creating a new thread to - service each connection. The default is reactive. - <P> - TAO also supports the thread-pool concurrency model - but this is implemented by the user, creating multiple - threads that call <CODE>ORB::run()</CODE> and using - the <CODE>-ORBReactorType tp</CODE> option. - </P> - </TD> - </TR> - <TR> - - <TD><a name="server_timeout"><CODE>-ORBThreadPerConnectionTimeout</CODE></a> - <EM>milliseconds</EM></TD> - <TD>In many platforms it is impossible to interrupt the server - threads created by the - <code>thread-per-connection</code> model. - This is because these threads are blocked in - <CODE>read()</CODE> operations (and not in - <CODE>select()</CODE>). - As a workaround, the server threads - periodically poll the ORB to find out if they should - shutdown. - This option controls the period of the polling, - expressed in milliseconds. - Applications that do not shutdown, or that can otherwise - ensure that no server threads will be running at - shutdown (for example if all the clients terminate - before the server) can disable the polling using the - magic value <CODE>INFINITE</CODE>. - - <P> - If the option is not provided then the ORB uses the - compile time flag - <CODE>TAO_DEFAULT_THREAD_PER_CONNECTION_TIMEOUT</CODE>, - this flag also expresses the time in milliseconds (as - a string constant) and the magic value - <CODE>"INFINITE"</CODE> can be used to disable polling - entirely. This yields a slight performance improvement - (around 1%). - </P> - </TD> - </TR> - <TR> - <TD><CODE>-ORBActiveObjectMapSize</CODE> <EM>active object map - size</EM></TD> - <TD>Specify the size of the active object map. If not - specified, the default value is 64.</TD> - </TR> - <TR> - - <TD><CODE>-ORBUseridPolicyDemuxStrategy</CODE> <EM>user id policy - based demultiplexing strategy</EM></TD> - <TD>Specify the demultiplexing - lookup strategy to be used with the user id policy. The - <EM>demultiplexing strategy</EM> can be one of <CODE>dynamic</CODE> or - <CODE>linear</CODE>. This option defaults to use the - <CODE>dynamic</CODE> strategy. </TD> - </TR> - <TR> - - <TD><CODE>-ORBSystemidPolicyDemuxStrategy</CODE> <EM>system id policy - based demultiplexing strategy</EM></TD> - - <TD>Specify the demultiplexing lookup strategy to be used with the - system id policy. The <EM>demultiplexing strategy</EM> can be - one of <CODE>dynamic</CODE>, <CODE>linear</CODE>, or - <CODE>active</CODE>. This option defaults to use the - <CODE>dynamic</CODE> strategy when - <CODE>-ORBAllowReactivationOfSystemids</CODE> is true, and to - <CODE>active</CODE> strategy when - <CODE>-ORBAllowReactivationOfSystemids</CODE> is false. </TD> - - </TR> - <TR> - - <TD><CODE>-ORBUniqueidPolicyReverseDemuxStrategy</CODE> <EM>unique id - policy based reverse demultiplexing strategy</EM></TD> - <TD>Specify the - reverse demultiplexing lookup strategy to be used with the unique id - policy. The <EM>reverse demultiplexing strategy</EM> can be one of - <CODE>dynamic</CODE> or <CODE>linear</CODE>. This option defaults to - use the <CODE>dynamic</CODE> strategy. </TD> - </TR> - <TR> - - <TD><CODE>-ORBAllowReactivationOfSystemids</CODE> <EM>allows - reactivation of system ids</EM></TD> - <TD>Specify whether system ids - can be reactivated, i.e., once an id that was generated by the system - has be deactivated, will the user reactivate a new servant using the - old id. If the user is not going to use this feature, the IORs can be - shortened, an extra comparison in the critical upcall path removed, - and some memory on the server side can be saved. The - <CODE>ORBAllowReactivationOfSystemids</CODE> can be <CODE>0</CODE> or - <CODE>1</CODE>. This option defaults to <CODE>1</CODE>. </TD> - </TR> - <TR> - - <TD><CODE>-ORBActiveHintInIds</CODE> <EM>adds an active hint in - ids</EM></TD> - <TD>Specify whether an active hint should be added to - ids. With active hints, ids can be found quickly. However, they lead - to larger IORs. Note that this option is disregarded - <CODE>-ORBAllowReactivationOfSystemids</CODE> is set to - <CODE>0</CODE>. The <EM>-ORBActiveHintInIds</EM> can be <CODE>0</CODE> - or <CODE>1</CODE>. This option defaults to <CODE>1</CODE>. </TD> - </TR> - <TR> - - <TD><CODE>-ORBPoaMapSize</CODE> <EM>poa map size</EM></TD> - <TD>Specify - the size of the poa map. If not specified, the default value is - 24.</TD> - </TR> - <TR> - - <TD><CODE>-ORBPersiententidPolicyDemuxStrategy</CODE> <EM>persistent - id policy based demultiplexing strategy</EM></TD> - <TD>Specify the - demultiplexing lookup strategy to be used with the persistent id - policy. The <EM>demultiplexing strategy</EM> can be one of - <CODE>dynamic</CODE> or <CODE>linear</CODE>. This option defaults to - use the <CODE>dynamic</CODE> strategy. </TD> - </TR> - <TR> - - <TD><CODE>-ORBTransientidPolicyDemuxStrategy</CODE> <EM>transient id - policy based demultiplexing strategy</EM></TD> - <TD>Specify the - demultiplexing lookup strategy to be used with the transient id - policy. The <EM>demultiplexing strategy</EM> can be one of - <CODE>dynamic</CODE>, <CODE>linear</CODE>, or - <CODE>active</CODE>. This option defaults to use the - <CODE>active</CODE> strategy. </TD> - </TR> - <TR> - - <TD><CODE>-ORBActiveHintInPOANames</CODE> <EM>adds an active hint in - poa names</EM></TD> - <TD>Specify whether an active hint should be added - to poa names. With active hints, poa names can be found quickly. - However, they lead to larger IORs. The - <EM>-ORBActiveHintInPOANames</EM> can be <CODE>0</CODE> or - <CODE>1</CODE>. This option defaults to <CODE>1</CODE>. </TD> - </TR> - <TR> - - <TD><CODE>-ORBThreadFlags</CODE> <EM>thread flags</EM></TD> - <TD>Specify the flags used for thread creation. Flags can be any - logical-OR combination of <CODE>THR_DETACHED</CODE>, - <CODE>THR_BOUND</CODE>, <CODE>THR_NEW_LWP</CODE>, - <CODE>THE_SUSPENDED</CODE>. The default is <CODE>THR_BOUND | - THR_DETACHED</CODE> . </TD> - </TR> - <TR> - - <TD><CODE>-ORBPOALock</CODE> <EM>lock type</EM></TD> - <TD><a - name="-ORBPOALock"></a>Specify the type of lock to be used for POA - accesses. Possible values for <em>lock type</em> are - <code>thread</code>, which specifies that an inter-thread mutex is - used to guarantee exclusive access, and <code>null</code>, which - specifies that no locking be performed. The default is - <code>thread</code>.</TD> - </TR> -<!-- - <TR> - - <TD><CODE>-ORBEventLoopLock</CODE> <EM>lock type</EM></TD> - <TD><font color=red>Somebody document me.</font></TD> - </TR> - <TR> ---> - <TD><CODE>-ORBConnectorLock</CODE> <EM>lock type</EM></TD> - <TD><a - name="-ORBConnectorLock"></a>This option has been moved to the - client strategy factory.</TD> - </TR> - -</TABLE> -</P> -</blockquote> - -<H3><CODE>TAO_Default_Client_Strategy_Factory</CODE><A NAME="DefaultClient"></A></H3> - -<BLOCKQUOTE> -<P><TABLE BORDER="2" CELLSPACING="2" CELLPADDING="0" > - <TR> - <TH>Option</TH> - <TH>Description</TH> - </TR> - <TR> - <TD><CODE><a name="#-ORBProfileLock">-ORBProfileLock</a></CODE> <EM>which</EM></TD> - <TD> - Specify the kind of synchronization primitive for the - Profiles. - Default is <code>thread</code>, which means that a regular thread - mutex is used. The - second option is <code>null</code>, which means a null lock is used. - This makes sense in case of optimizations and is allowed when - no forwarding is used or only a single threaded client. - </TD> - </TR> - <TR> - <TD><CODE>-ORBClientConnectionHandler</CODE> <EM>MT / ST / RW</EM></TD> - - <TD><A name="-ORBClientConnectionHandler"></a> - - ST means use the single-threaded client connection handler, i.e., the - leader follower model will not be used. However, ST does support - nested upcalls and handling of new requests while waiting for the - reply from a server. <p> - - MT means use the multi-threaded client connection handler which uses - the leader follower model. This model allows the use of multiple - threads with a single Reactor. <p> - - RW selects a strategy that simply blocks in recv() when waiting for a - response from the server instead of waiting in the Reactor. The RW - strategy only works when the application does not have to worry about - new request showing up when waiting for a response. Therefore, this - strategy is appropriate only for "pure" clients. Note that - applications with nested upcalls are not "pure" clients. Also note - that this strategy will only effect two way calls, since there is no - waiting for 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> - - Default for this option is MT. - - </TD> - </TR> - - <TR> - <TD><CODE>-ORBTransportMuxStrategy</CODE> <EM>EXCLUSIVE / MUXED</EM></TD> - - <TD><A name="-ORBTransportMuxStrategy"></a> - - EXCLUSIVE means that the Transport does not multiplex requests on a - connection. At a time, there can be only one request pending on a - connection. <p> - - MUXED means that Transport multiplexes more than one request at the - same time on a connection. This is very important for getting the - Asynchronous Method Invocation model to work. This is not - implemented yet. <p> - - Default for this option is EXCLUSIVE. - - </TD> - </TR> - - <TR> - <TD><CODE>-ORBConnectorLock</CODE> <EM>lock type</EM></TD> - <TD><a - name="-ORBConnectorLock"></a>Specify the type of lock to be used by - the connector. Possible values for <em>lock type</em> are - <code>thread</code>, which specifies that an inter-thread mutex is - used to guarantee exclusive access, and <code>null</code>, which - specifies that no locking be performed. The default is - <code>thread</code>. - </TD> - </TR> - -</TABLE> -</P> -</BLOCKQUOTE> -</blockquote> - -<P><HR><P> -Back to the TAO <A HREF="components.html">components documentation</A>. - -<!--#include virtual="/~schmidt/cgi-sig.html" --> -</HTML> |