diff options
Diffstat (limited to 'TAO/docs/configurations.html')
| -rw-r--r-- | TAO/docs/configurations.html | 451 |
1 files changed, 0 insertions, 451 deletions
diff --git a/TAO/docs/configurations.html b/TAO/docs/configurations.html deleted file mode 100644 index 61a0f82916c..00000000000 --- a/TAO/docs/configurations.html +++ /dev/null @@ -1,451 +0,0 @@ -<HTML> - <HEAD> - <META NAME="GENERATOR" CONTENT="Adobe PageMill 2.0 Mac"> - <TITLE>Configuring TAO's Components</TITLE> - </HEAD> -<!-- $Id$ --> -<BODY text = "#000000" -link="#000fff" -vlink="#ff0f0f" -bgcolor="#ffffff"> - -<HR><P> - -<H3 ALIGN=CENTER>Configuring TAO's Components</H3> - -<H3>Overview</H3> - -<p>As described in the <a href="Options.html">options</a> -documentation, various components in TAO can be customized by -specifying options for those components. This document illustrates -how to combine these options in order to affect ORB behavior and -performance, particularly its <A -HREF="http://www.cs.wustl.edu/~schmidt/CACM-arch.ps.gz">concurrency -model</A>.</P> - -<p>TAO configures itself using the ACE Service Configurator -framework. Thus, options are specified in the familiar -<code>svc.conf</code> file (if you want to use a different file -name, use the <a -href="Options.html#svcfonf"><code>-ORBsvcconf</code></a> -option).</p> - -<HR><P> - -<H3>Roadmap</H3> - -<blockquote> -<P>Details for the following configurations are provided.</P> - -<UL> - <li><b><a href="#comp">Configurating key components</a>:</b> - <ul> - <li><a href="#concurrency">Server Concurrency Strategy.</a> - <li><a href="#orb">ORB and other resources.</a> - <li><a href="#poa">POA.</a> - <li><a href="#coltbl">Collocation Table.</a> - <li><a href="#iiopprofile">Forwarding IIOP Profile</a> - </ul> - <li><b><a href="#examples">Configuration examples</a></b> - <ul> - <LI><A HREF="#reactive">Single-threaded, reactive model.</A> - <LI><A HREF="#tpc">Multiple threads, thread-per-connection model.</A> - <LI><A HREF="#multiorb">Multiple threads, ORB-per-Reactor-thread model.</A> - <LI><A HREF="#multiorb-tpc">Multiple threads, ORB-per-thread, - thread-per-connection model.</A> - <li><a href="#tpool">Multiple threads, thread-pool model.</a> - (Not yet implemented.) - <li><a href="#multiorb-tpool">Multiple threads, - ORB-per-thread, thread-pool model.</a> (Not yet implemented.) - <li>Each configuration has the following information:</p> - - <table border=2 width="70%" cellspacing="2" cellpadding="0"> - <tr align=left> - <th> Typical Use </th> - <td> A brief description of the scenario and its typical use. </td> - </tr> - - <tr align=left> - <th>Number of Threads</th> - <td>The number of threads used by ORB-related activities.</td> - </tr> - - <tr align=left> - <th>Thread Creator</th> - <td>Identifies the creator of the threads discussed above.</td> - </tr> - - <tr align=left> - <th>Resource Location</th> - <td>Where information on various resources is stored.</td> - </tr> - - <tr align=left> - <th>Thread task</th> - <td>Describes what task is undertaken for each thread.</td> - </tr> - - <tr align=left> - <th>Options</th> - <td>Specifies the options for each service in order to utilize this configuration.</td> - </tr> - </table> - </ul> -</UL> - - -</blockquote> - -<HR><P> -<h3>Configuring key components<a name="comp"></a></h3> - -<ul> - <li><b><a name="concurrency">Server concurrency strategy</a></b> - specifies the concurrency strategy an ORB uses. It says nothing - about how many ORBs (or, threads) are there in a process.<p> - - <ul> - <li><code>reactive</code>: The ORB handles requests - reactively, i.e., the ORB runs in one thread and service - multiple requests/connections simultaneously using - "<code>select</code>" call. You can have multiple ORBs - accepting requests reactively and running in separate - threads.<p> - - <li><code>thread-per-connection</code>: The ORB handles new - connections by spawning a new thread whose job is to - service requests coming from the connection. The new - threads inherits all properties from the ORB threads (see - below.) <p> - - <li><code>thread-pool</code> (not yet implemented): ... to be - continued ... <p> - - </ul><p> - - <li><b><a name="orb">ORB and other resources.</a></b><p> - - <ul> - <li><code>global</code>: There's only one ORB process-wide. - <code>ORB_init () </code>must be called only once. Every - thread accesses the same ORB. <p> - - <li><code>tss</code>: When using <code>tss</code> ORB, the - programmer is responsible for spawning the ORB threads and - setting up the ORB by calling <code>ORB_init ()</code> for - each ORB threads. Any ORB spawned thread (i.e., thru - thread-per-connection) shares the same resource the - spawning ORB uses.<p> - - </ul><p> - - <li><b><a name="poa">POA.</a></b><p> - - <ul> - <li><code>global</code>: All ORBs share the same POA. The - advantage of using a global POA is that once an object is - registered to the POA under an ORB, it can be externalized - from other ORB.<p> - - <li>per ORB (<code>tss</code>): Each ORB has its own POA, - which means, the programmer should also instantiate the POA - for each ORB (otherwise, a default RootPOA gets created, - which might not be what you what and thus, is discouraged.)<p> - - </ul><p> - - <li><b><a name="coltbl">Collocation Table:</a></b> <sup>*</sup>Care - must be taken when using CORBA objects to control the ORB - directly. For you are actually executing the collocated object, - not in the object's ORB context, but in the calling ORB's - context.<p> - - <ul> - <li><code>global</code>: Process keeps a global collocation - table which contains tuples of listening endpoint and its - corresponding RootPOA. <p> - - <LI>per ORB (<code>tss</code>): At this moment, since TAO only - supports one listening endpoint per ORB, there is no - per-ORB collocation Table. Checking of collocated objects - is done by comparing object's IIOP profile and the calling - ORB's listening endpoint.<p> - - </ul><p> - - <li><b><a name="iiopprofile">Forwarding IIOP Profile:</a></b> - In the case of multiple threads using the same <code>CORBA::Object</code> and - using forwarding, it is necessary to protect the forwarding - <code>IIOP_Profile</code>, which is part of the <code>IIOP_Object</code>, - which is part of the CORBA::Object against multiple access. Therefore - a mutex lock is used by default to ensure proper access. Using - the switch <code>-ORBiiopprofilelock</code> this policy can - be deactivated specifying <code>-ORBiiopprofilelock null</code>. - A motivation to do this might be performance reasons in cases, - where no forwarding is used or no multithreading with access - to shared <code>CORBA::Object</code>'s. Deactivating forces the ORB - to use a null mutex, which does introduce only a very small - overhead, compared with overhead introduced by a regular mutex lock. - <p> - - -</ul> - - - -<HR><P> -<H3>Configuration Example<a name="examples"></a></H3> - -<UL> -<LI>Single-threaded, reactive model.<A NAME="reactive"></A> - -<p> -<table border=2 width="90%" cellspacing="2" cellpadding="0"> - <th align=left>Typical Use</th> - <td> - This is the default configuration of TAO, where one thread handles - requests from multiple clients via a single Reactor. It is - appropriate when the requests (1) take a fixed, relatively uniform - amount of time and (2) are largely compute bound. - </td> -</tr> - -<tr align=left> - <th>Number of Threads</th> - <td>1</td> -</tr> - -<tr align=left> - <th>Thread Creator</th> - <td>OS or whomever creates the main ORB thread in a process.</td> -</tr> - -<tr align=left> - <th>Resource Location</th> - <td>Resources are stored process-wide.</td> -</tr> - -<tr align=left> - <th>Thread task</th> - <td>The single thread processes all connection requests and CORBA messages.</td> -</tr> - -<tr align=left> - <th>Options</th> - <td> - <code>TAO_Resource_Manager</code>: <code>-ORBresources global</code><br> - <code>TAO_Server_Strategy_Factory</code>: <code>-ORBconcurrency reactive</code> - </td> -</tr> -</table> -</p> - -<LI>Multiple threads, thread-per-connection model.<A NAME="tpc"></A> - -<p> -<table border=2 width="90%" cellspacing="2" cellpadding="0"> -<tr align=left> - <th>Typical Use</th> - <td>This configuration spawns a new thread to serve requests - from a new connection. This approach works well when - there are multiple connections active simultaneously and each - request-per-connection may take a fair amount of time to - execute. -</tr> - -<tr align=left> - <th>Number of Threads</th> - <td>1 plus the number of connections.</td> -</tr> - -<tr align=left> - <th>Thread Creator</th> - <td>Programmer must set up the main thread which is - responsible to create new threads for new connections.</td> -</tr> - -<tr align=left> - <th>Resource Location</th> - <td>Process-wise.</td> -</tr> - -<tr align=left> - <th>Thread task</th> - <td>The main thread handles new connections and spawns new - threads for them. Other threads handle requests for - established connections.</td> -</tr> - -<tr align=left> - <th>Options</th> - <td> - <code>TAO_Resource_Manager</code>: <code>-ORBresources global</code><br> - <code>TAO_Server_Strategy_Factory</code>: <code>-ORBconcurrency thread-per-connection</code> - </td> -</tr> - -</table> -</p> - -<LI>Multiple threads, ORB-per-thread model.<A NAME="multiorb"></A> - -<p> -<table border=2 width="90%" cellspacing="2" cellpadding="0"> -<tr align=left> - <th>Typical Use</th> - <td>In this configuration, there multiple ORBs per process each - running in its own thread. Each thread handles requests - reactively. It's good for hard real-time applications that require - different thread priorities for the various ORBs.</td> -</tr> - -<tr align=left> - <th>Number of Threads</th> - <td>The number of ORBs.</td> -</tr> - -<tr align=left> - <th>Thread Creator</th> - <td>The main process (thread).</td> -</tr> - -<tr align=left> - <th>Resource Location</th> - <td>Thread specific.</td> -</tr> - -<tr align=left> - <th>Thread task</th> - <td>Service the requests from associating ORB.</td> -</tr> - - <tr align=left> - <th>Options</th> - <td> - <code>TAO_Resource_Manager</code>: <code>-ORBresources tss</code><br> - <code>TAO_Server_Strategy_Factory</code>: <code>-ORBconcurrency reactive</code> - </td> -</tr> -</table> -</p> - -<LI>Multiple threads, ORB-per-thread, thread-per-connection -model.<A NAME="multiorb-tpc"></A></H3> - -<p> -<table border=2 width="90%" cellspacing="2" cellpadding="0"> -<tr align=left> - <th>Typical Use</th> - <td>This approach provides a range of thread priorities plus connections - that don't interfere with each others.</td> -</tr> - -<tr align=left> - <th>Number of Threads</th> - <td>Number of ORBs plus number of connections.</td> -</tr> - -<tr align=left> - <th>Thread Creator</th> - <td>Main threads creates threads running ORBs. They, in - turns, create connection handling threads.</td> -</tr> - -<tr align=left> - <th>Resource Location</th> - <td>Thread specific.</td> -</tr> - -<tr align=left> - <th>Thread task</th> - <td>There are ORB threads which handle connection requests - and handler threads which service requests form - establiched connections.</td> -</tr> - -<tr align=left> - <th>Options</th> - <td> - <code>TAO_Resource_Manager</code>: <code>-ORBresources tss</code><br> - <code>TAO_Server_Strategy_Factory</code>: <code>-ORBconcurrency thread-per-connection</code> - </td> -</tr> - -</table> -</p> - -<LI><A NAME="tpool">Multiple threads, thread-pool model.</A> -(Not yet implemented.) - -<p> -<table border=2 width="90%" cellspacing="2" cellpadding="0"> -<tr align=left> - <th>Typical Use</th> - <td>This model implements a highly optimized thread pool that - minimizes context switching, synchronization, dynamic memory - allocations, and data movement between threads.</td> -</tr> - -<tr align=left> - <th>Number of Threads</th> - <td>The number of threads used by ORB-related activities.</td> -</tr> - -<tr align=left> - <th>Thread Creator</th> - <td>Identifies the creator of the threads discussed above.</td> -</tr> - -<tr align=left> - <th>Resource Location</th> - <td>Where information on various resources is stored.</td> -</tr> - -<tr align=left> - <th>Thread task</th> - <td>Describes what task is undertaken for each thread.</td> -</tr> -</table> -</p> - -<LI>Multiple threads, ORB-per-thread, thread-pool model.<A -NAME="multiorb-tpool"></A> (Not yet implemented.) - -<p> -<table border=2 width="90%" cellspacing="2" cellpadding="0"> -<tr align=left> - <th>Typical Use</th> - <td>A brief description of the scenario and its typical use.</td> -</tr> - -<tr align=left> - <th>Number of Threads</th> - <td>The number of threads used by ORB-related activities.</td> -</tr> - -<tr align=left> - <th>Thread Creator</th> - <td>Identifies the creator of the threads discussed above.</td> -</tr> - -<tr align=left> - <th>Resource Location</th> - <td>Where information on various resources is stored.</td> -</tr> - -<tr align=left> - <th>Thread task</th> - <td>Describes what task is undertaken for each thread.</td> -</tr> -</table> -</p> - -</UL> -</blockquote> - -<P><HR><P> -Back to the TAO <A HREF="components.html">components documentation</A>. - -<!--#include virtual="/~schmidt/cgi-sig.html" --> -</BODY> -</HTML> |