As described in the options 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 concurrency model.
TAO configures itself using the ACE Service Configurator framework. Thus, options are specified in the familiar svc.conf file (if you want to use a different file name, use the -ORBsvcconf option). You can also setup default configurations for your programs. Please see the Programming Considerations for more detailed discussion on this.
Details for the following configurations are provided.
- Configurating key components:
- Server Concurrency Strategy.
- ORB and other resources.
- POA.
- Collocation Table.
- Forwarding IIOP Profile
- orbsvcs Library
- Configuration examples
- Single-threaded, reactive model.
- Multiple threads, thread-per-connection model.
- Multiple threads, ORB-per-Reactor-thread model.
- Multiple threads, ORB-per-thread, thread-per-connection model.
- Multiple threads, thread-pool model. (Not yet implemented.)
- Multiple threads, ORB-per-thread, thread-pool model. (Not yet implemented.)
- Each configuration has the following information:
Typical Use A brief description of the scenario and its typical use. Number of Threads The number of threads used by ORB-related activities. Thread Creator Identifies the creator of the threads discussed above. Resource Location Where information on various resources is stored. Thread task Describes what task is undertaken for each thread. Options Specifies the options for each service in order to utilize this configuration. - Programming considerations
- Configuration for homogenous systems
Please see the ORBSVCS
Makefile
for the default setting of TAO_ORBSVCS
.
Please note that the Naming Service will always be built, even
if Naming is not specified in TAO_ORBSVCS
. That's
because many examples, tests, and presumably applications use it.
Typical Use | 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. |
---|---|
Number of Threads | 1 |
Thread Creator | OS or whomever creates the main ORB thread in a process. |
Resource Location | Resources are stored process-wide. |
Thread task | The single thread processes all connection requests and CORBA messages. |
Options | TAO_Resource_Manager: -ORBresources global
TAO_Server_Strategy_Factory: -ORBconcurrency reactive |
Check out the Param_Test for an example of this configuration.
Typical Use | 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. |
---|---|
Number of Threads | 1 plus the number of connections. |
Thread Creator | Programmer must set up the main thread which is responsible to create new threads for new connections. |
Resource Location | Process-wise. |
Thread task | The main thread handles new connections and spawns new threads for them. Other threads handle requests for established connections. |
Options | TAO_Resource_Manager: -ORBresources global
TAO_Server_Strategy_Factory: -ORBconcurrency thread-per-connection |
IDL_Cubit is a good example on using multiple threads, thread-per-connection configuration.
Typical Use | 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. |
---|---|
Number of Threads | The number of ORBs. |
Thread Creator | The main process (thread). |
Resource Location | Thread specific. |
Thread task | Service the requests from associating ORB. |
Options | TAO_Resource_Manager: -ORBresources tss
TAO_Server_Strategy_Factory: -ORBconcurrency reactive |
Typical Use | This approach provides a range of thread priorities plus connections that don't interfere with each others. |
---|---|
Number of Threads | Number of ORBs plus number of connections. |
Thread Creator | Main threads creates threads running ORBs. They, in turns, create connection handling threads. |
Resource Location | Thread specific. |
Thread task | There are ORB threads which handle connection requests and handler threads which service requests form establiched connections. |
Options | TAO_Resource_Manager: -ORBresources tss
TAO_Server_Strategy_Factory: -ORBconcurrency thread-per-connection |
MT_Cubit is a good example on using multiple threads, ORB-per-thread, and thread-per-connection configuration.
Typical Use | This model implements a highly optimized thread pool that minimizes context switching, synchronization, dynamic memory allocations, and data movement between threads. |
---|---|
Number of Threads | The number of threads used by ORB-related activities. |
Thread Creator | Identifies the creator of the threads discussed above. |
Resource Location | Where information on various resources is stored. |
Thread task | Describes what task is undertaken for each thread. |
Typical Use | A brief description of the scenario and its typical use. |
---|---|
Number of Threads | The number of threads used by ORB-related activities. |
Thread Creator | Identifies the creator of the threads discussed above. |
Resource Location | Where information on various resources is stored. |
Thread task | Describes what task is undertaken for each thread. |
The plain vanilla approach is do nothing. All TAO components use their default settings as described in this document.
The most common use case is to use a file called
svc.conf
. On most platforms, TAO programs
automatically search and read in the file. The disadvantage of
this approach is you always need a svc.conf
file if
you want to do use non-default configuration.
You can use -ORBsvcconf filename
to use
a config file that is not called svc.conf
.
Specifying -ORBsvcconf
exclude the reading of
default svc.conf
file.
If you don't want the application users to worry about
setting up or knowing about svc.conf
files, you can
call TAO_Internal::default_svc_conf_entries()
before calling the first ORB_init()
in your program
to set up the default svc.conf entries. In this case, if a TAO
application cannot find a svc.conf file, it will configure TAO's
components using the default settings. You can still use a
svc.conf
file or use -ORBsvcconf
option to tune the program.
TAO programs evaluate the configuration settings in the following order,
-ORBsvcconf
command-line
option, if one exist. Otherwise, the
svc.conf
in the start-up directory will be
evaluated, if one exist.
TAO_Internal::default_svc_conf_entries()
, if
ones exist.
Notice that the first encountered component settings are
always the ones take effect. For example, if you set the entries
for Resource_Factory
and
Server_Strategy_Factory
using
TAO_Internal::default_svc_conf_entries()
in a
program and you also have a file called svc.conf
which has an entry for Resource_Factory
. This
program will use the entry for Resource_Factory
in
the svc.conf
file, the entry for
Server_Strategy_Factory
set in the program, and the
in-stock Client_Strategy_Factory
that TAO defines.
Some platforms do not support reading of svc.conf
files or you would rather not to use the feature. In this case,
you must define TAO_PLATFORM_SVC_CONF_FILE_NOTSUP
in your ACE config.h
file and recompile TAO
library. In this case, a TAO program will not try to search for
the default svc.conf
file. However, if platform
support, you can still use -ORBsvcconf
to change
the program behavior temporarily.
On these platform, you can alter the default settings for
TAO components by defining the following macros in your
config.h
file:
TAO_DEFAULT_RESOURCE_FACTORY_ARGS
TAO_DEFAULT_SERVER_STRATEGY_FACTORY_ARGS
TAO_DEFAULT_CLIENT_STRATEGY_FACTORY_ARGS
The ACE Makefiles fakesvcconf
flag can be
used to define TAO_PLATFORM_SVC_CONF_FILE_NOTSUP
.
To define that macro, just add fakesvcconf=1
to
your make
invocation.
See orbconf.h
for
an example.
Many real-time applications run on homogenous environments, TAO (and ACE) can take advantage of this fact by simplifying the server side demarshaling; to enable this feature you have to edit the $ACE_ROOT/ace/OS.h file and enable the macro ACE_DISABLE_SWAP_ON_READ.
In this systems it is also common that server and the client startup and shutdown simultaneously, in those circumstances there is no need to check the timestamps in the POA, another macro (POA_NO_TIMESTAMP) can be used for this purpose.
Users running in embebbed systems may also need to modify the default options for TAO, the macros TAO_DEFAULT_RESOURCE_FACTORY_ARGS, TAO_DEFAULT_CLIENT_STRATEGY_FACTORY_ARGS and TAO_DEFAULT_SERVER_STRATEGY_FACTORY_ARGS can be used for those purposes. If the footprint size is an issue users may consider writing custom strategy factories that only create the right strategies, this eliminates the parsing code for the different options.
If the only ORB running is TAO and there is no need to be IIOP interoperable the option -ORBgioplite can be used to reduce the message size and the processing time.
Some embedded systems run without the benefit of a DNS server, in that case they can use the -ORBdotteddecimaladdresses option; the ORB will avoid the use of hostnames in the profiles it generates, thus clients don't need to do any name resolution. The compile-time define TAO_USES_DOTTED_DECIMAL_ADDRESSES in $TAO_ROOT/tao/orbconf.h to make this the default behavior.
As the reader will note this is a delicate configuration option, the rule of thumb should be not to use ORB-per-thread unless it is really required.
While waiting for this response new requests to the local ORB can arrive, this is the so-called nested upcall support. TAO supports two mechanisms for handling nested upcalls, the default uses the leader-follower model to allow multiple threads to wait on a single reactor for several concurrent requests; sometimes this configuration can be an overkill, if only one thread is using a reactor at the same time a lighter weight implementation can be used.
This configuration is controled by the -ORBclientconnectionhandler option, good opportunities to use this option are:
In some cases the user may gain access to the CDR stream buffer: TAO makes no copies when demarshaling octet sequences, instead the octet sequence simply points to the CDR buffer, since the octet sequence does not own this buffer a copy must be made if the user wants to keep the buffer after the upcall.
The user can, however, increase the reference count on the CDR stream buffer, thus allowing her to extend the lifetime of this buffer. Still passing this buffer to another thread and attempting to release it in that thread will result in some memory leak or corruption. Users willing to use this feature of TAO can still do so, if they use a global allocator for their input CDR stream, but that will introduce extra locking on the critical path.
As the reader can see this is an option that has limited applicability and requires careful consideration of the tradeoffs involved.
Back to the TAO components documentation.