![]() |
![]() |
|
|
Creating Multithreaded CORBA Server Applications
This topic includes the following sections:
Overview
This topic includes the following sections:
Introduction
Designing an application to use multiple, independent threads provides concurrency within an application and can improve overall throughput. Using multiple threads enables applications to be structured efficiently with threads servicing several independent tasks in parallel. Multithreading is particularly useful when:
Historically, industry-wide, multithreaded applications have been complicated to design and implement. The support provided by BEA Tuxedo simplifies this complexity by managing threads within a CORBA server environment.
The BEA Tuxedo software supports server applications that have the following multithreading characteristics (see Figure 4-1):
Figure 4-1 Multithreaded CORBA Server Application
Generally, the BEA Tuxedo software creates and manages threads on behalf of a server application. Building multithreaded server applications affects how you use the TP Framework, implement servants, and design objects that create their own threads.
The BEA Tuxedo software allows you to implement either the thread-per-request model or a thread-per-object model. Each model is explained in Threading Models.
Requirements, Goals, and Concepts
Some computer operations take a substantial amount of time to complete. A multithreaded design can significantly reduce the wait time between the request and completion of operations. This is true in situations when operations perform a large number of I/O operations such as when accessing a database, invoking operations on remote objects, or are CPU-bound on a multiprocessor machine. Implementing multithreading in a server process can increase the number of requests a server processes in a fixed amount of time.
The primary requirement for multithreaded server applications is the simultaneous handling of multiple client requests. The motivations for developing this type of server are to:
This is achieved by allowing multiple server tasks to proceed independently using conventional programming abstractions.
This is achieved by taking advantage of the parallel processing capabilities of multiprocessor hardware platforms and overlapping computation with communication.
By associating separate threads with different server tasks, clients do not block each other for an extended period of time.
Some applications are easier to code when you use separate threads to interact with different remote procedure calls (RPCs) and conversations.
When wrapping legacy applications or databases in a CORBA server, implementations can interact with more than one legacy application at a time.
Because one server can dispatch multiple service threads, the number of servers your application requires can be reduced.
However, a multithreaded design is not without cost. In general, multithreaded server applications require more complicated synchronization strategies than single-threaded servers. An application developer must write thread-safe code. Additionally, the overhead of creating a thread to handle a request might be greater than the potential benefit of parallelism. The actual performance of a particular concurrency model depends on the following factors:
Are the requests of long or short duration?
Are the threads managed in the operating system kernel, in a library in user space, or some combination of both?
How much additional overhead is introduced by repeatedly setting up and tearing down connections?
Do replication, dynamic load balancing, or other factors affect performance?
While threading libraries provide the mechanisms for creating concurrency models, developers are ultimately responsible for knowing how to use the mechanisms successfully. By studying design patterns, application developers can master the subtle differences and make better design choices for different situations.
Threading Models
There are a number of different models you can use for designing concurrency in servers. The following sections describe the thread-per-request model, the thread-per-object model, the thread pool, and how the BEA Tuxedo software implements each model. A specific server is designed for either the thread-per-request model or the thread-per-object model.
Thread-Per-Request Model
In this model, each request from a client is processed in a different thread of control. This model is useful when a server typically receives requests of long duration from multiple clients. It is less useful for requests of short duration due to the overhead of creating a new thread for each request. Each time a new request arrives, BEA Tuxedo associates that request with a thread and executes it. Because a multithreaded application server process can host more than one thread at a time, it can simultaneously execute more than one client request at a time. BEA Tuxedo controls the association of a request to a thread, therefore, applications do not need to explicitly create threads unless the applications require a greater degree of control than that provided by BEA Tuxedo.
The thread-per-request model requires that you design your application servers to be thread-safe, which means that you must implement concurrency mechanisms to control access to data that might be shared among multiple server objects. The need to use concurrency control mechanisms increases the complexity of the applications development process. Additionally, if many clients make requests simultaneously, this design can consume a large number of operating system resources.
Thread-Per-Object Model
The thread-per-object model associates each active object in the server process with a single thread at any one time. Each request for an object establishes an association between a dispatch thread and the object. Serial requests for the same object can be serviced by different threads. A specific thread can be shared by multiple objects.
The Thread Pool
Thread pools are a means to reduce the cost of managing threads. At startup and as needed, threads are created, assigned, and released to a pool of available threads where the thread waits until it is needed again to process future requests. Thread pools can be used to support any of the threading models previously described. For example, a thread may be allocated for a request in a thread-per-request model, used for the method execution, and released back to the pool.
Allocating and deallocating threads can be time-consuming and expensive, especially for short-lived requests and objects. Thread pools provide a means of reducing the cost of managing threads. During startup, or as needed, threads are created, assigned, and released by the BEA Tuxedo software to a pool of available threads. A thread exists in the pool and waits until it is needed to process future requests.
The initial and ultimate size of the BEA Tuxedo thread pool for an application server process is controlled through settings in the server configuration file. At startup, the minimum pool size is pre-allocated. As requests arrive to be serviced, the BEA Tuxedo software assigns a thread from the pool to handle the request. If the pool does not contain an available thread to process the request and the pool has not been filled, the BEA Tuxedo software creates a new thread to handle the request. If a request arrives when there are no threads available in the pool, and no new threads can be created, the request will be queued until a thread is available.
Thread pools are appropriate for situations in which you want to limit the amount of system resources that can be consumed for server threading. When a thread pool is used, client requests are executed concurrently until the number of simultaneous requests exceeds the number of threads in the pool.
The BEA Tuxedo thread pool has the following characteristics and behavior:
Reentrant Servants
The BEA Tuxedo software provides the capability for an object to invoke operations on itself recursively. Using this capability requires a great deal of care in how you implement an object, because the application code must employ the operating system concurrency mechanisms needed to control access to shared state data. In some cases, such as with objects that implement the Process or Distribution Adapter design patterns, there is little or no shared state for an object, and it is relatively easy to support reentrancy.
BEA Tuxedo software also allows you to enable or prohibit reentrant method invocations on an active object. Reentrancy is disabled by default. If a request for an active object is received while the object is currently executing another request in a different thread, the following rules apply:
Note: The reentrant servant mechanism is available only when a server is started with the PER_REQUEST concurrency strategy specified.
For information about using this method, see the CORBA Programming Reference.
The Current Object
One of the most important attributes of a multithreaded CORBA server application environment is ensuring that the Current object is used and managed correctly. This ensures behavior such as the following:
The BEA Tuxedo product conforms to the multithreading model defined by the ORB Portability Specification, published by the OMG, which has been incorporated into the OMG CORBA specification. In the BEA Tuxedo product, operations on interfaces derived from CORBA::Current have access to the state associated with the thread in which operations are invoked, not to the state associated with the thread from which the Current object was obtained. The reason for this behavior is twofold:
When used in a multithreaded environments, the behaviors of the following objects are consistent with the ORB Portability Specification:
For example, when an application passes a transaction from one thread to another, the application should not use the CosTransactions::Current object. Instead, the application passes the CosTransactions::Control object to the other thread. To pass the CosTransctions::Current object would only allow the receiving thread to gain access to the transaction state associated with that thread.
Mechanisms for Supporting Multithreaded CORBA Servers
This section provides an overview of the following tools, APIs, and administrative capabilities in BEA Tuxedo CORBA that support multithreaded server applications:
Context Services
You can choose to create and manage your own threads in your object implementations. Other threads are managed automatically by the BEA Tuxedo CORBA software. The BEA Tuxedo CORBA software maintains context information internally for each thread that it creates and maintains. This required context information is used during the processing of CORBA requests. Since BEA Tuxedo CORBA has no knowledge of when an application creates and deletes its own threads, the context services mechanism allows programmers to initialize their own threads correctly, prior to calling BEA Tuxedo services, and to release any context resources that are no longer needed when a thread is deleted.
The following set of ORB methods satisfies the thread management requirements. Together these are called context services:
When an object creates a thread, the object invokes this operation on the ORB to obtain system context information that the object can pass onto the thread. This operation must be called from a thread that already has a context. For example, the thread in which a method was dispatched will already have a context. For information about using this operation, see ORB::get_ctx() in the CORBA Programming Reference.
When an object spawns a thread, the spawned thread typically retrieves the context information from the thread that invoked the get_ctx method. The spawned thread then uses the retrieved context information when invoking ORB::set_ctx to set the system context in which the spawned thread should execute. For information about using this operation, see ORB::set_ctx() in the CORBA Programming Reference.
When a spawned thread has completed its work, the thread invokes this method to dissociate itself from the system context. For information about using this operation, see ORB::clear_ctx() in the CORBA Programming Reference.
When a thread has completed its work, the thread invokes this method to inform the BEA Tuxedo system that resources associated with an application-managed thread can be released. For information about using this operation, see ORB::inform_thread_exit() in the CORBA Programming Reference.
Classes and Methods in the TP Framework
These classes and methods in the BEA Tuxedo TP Framework support multithreaded server applications:
To override the default implementations of the ServerBase class, an application developer can create a class that derives from ServerBase. In addition to ServerBase methods already supported, these methods are provided to support the implementation of multithreaded server applications:
These methods allow you to obtain a high-degree of granularity of control over the multithreading characteristics of your application. For information on how to use these methods see ServerBase Class in the CORBA Programming Reference.
This class provides these methods to support multithreaded server applications:
For information about using these methods, see Tobj_ServantBase Class in the CORBA Programming Reference.
Capabilities in the Build Commands
The buildobjserver and buildobjclient commands include the following thread-management capabilities.
The buildobjserver command includes command-line options for building multithreaded or single-threaded server applications.
Tools for Administration
The BEA Tuxedo system employs configuration files to assemble and run applications. Typically, the application developer creates these files, and BEA Tuxedo system administrators modify the contents of the file as necessary to satisfy application and system requirements.
The control parameters associated with the support of threads specify the following:
For more information about threads parameters in the UBBCONFIG file, see the section Sample UBBCONFIG File.
Running Single-threaded Server Applications in a Multithreaded System
The default behavior of the threading support provided in BEA Tuxedo CORBA is to emulate a single-threaded server support environment. To run a single-threaded CORBA application in a multithreaded environment, you do not need to change the server application code or the configuration files. However, before you run an existing single-threaded application, you must rebuild it using the buildobjserver and buildobjclient commands. If you do not specifically enable multithreading for a server application, the application runs as a single-threaded server.
Developing and Building Multithreaded CORBA Server Applications
This topic includes the following sections:
Using the buildobjserver Command
The buildobjserver command supports multithreaded CORBA server applications through the following capabilities:
Platform-specific Thread Libraries
Server applications generated by the buildobjserver command are compiled using the correct platform-specific compiler settings, and are linked using the correct platform-specific thread support libraries. This ensures compatibility with the shared libraries provided by the BEA Tuxedo software.
Specifying Multithreaded Support
When you create a CORBA server application to support multithreading, you must specify the -t option on the buildobjserver command when you build the application. At run time, the BEA Tuxedo system verifies compatibility between the executable program and the threading model selected in the CORBA server application configuration file UBBCONFIG. For information on how to set the threading model in the UBBCONFIG file, see the section Sample UBBCONFIG File.
Note: When you specify -t in your build of a CORBA server application, you should set the MAXDISPATCHTHREADS parameter in the UBBCONFIG file to a value greater than 1; otherwise, the CORBA server application will run as a single-threaded server.
Note: Multithreaded joint client/server implementations are not supported.
If you attempt to start a single-threaded executable with an incompatible threading model specification in the configuration file, these events occur:
Specifying an Alternate Server Class
If you implement your own Server class, inheriting from the ServerBase class, you must specify your alternate Server class in the buildobjserver command using the -b option. The buildobjserver command provides the following syntax to support the -b option:
buildobjserver [-v] [-o outfile] [-f {firstfiles|@def-file}]
[-l {lastfiles|@def-file}] [-r rmname] [-b bootserverclass] [-t]
In the preceding syntax, the value for bootserverclass specifies the C++ class to be used when the CORBA server application is booted. If you do not specify the -b option, the BEA Tuxedo system creates an instance of the class named Server.
When you specify the -b option, the Tuxedo system creates a main function for the alternate server class, and your project must supply a header file with the name you specified for bootserverclass on the -b option. The header file contains the definition of the alternate C++ class. This alternate Server class must inherit from the ServerBase class.
For example, if the command line specifies -b AslanServer, the application project must supply an AslanServer.h file. The AslanServer.h file is an example of a bootserverclass.h file. A bootserverclass file provides logic similar to this code sample:
Listing 4-1 Example of a bootserverclass.h File
// File name: AslanServer.h
#include <Server.h>
class AslanServer : public ServerBase {
public:
CORBA::Boolean initialize(int argc, char** argv);
void release();
Tobj_Servant create_servant(const char* interfaceName);
Tobj_Servant create_servant_with_id(const char* interfaceName,
const char* stroid);
CORBA::Boolean thread_initialize(int argc, char** argv);
void thread_release();
};
Using the buildobjclient Command
When you use the buildobjclient command to create a client application executable program, the application is compiled using the correct platform-specific compiler settings and linked using the correct thread support libraries for your operating system. This ensures that clients are compatible with the shared libraries provided by the BEA Tuxedo software.
Creating Non-reentrant Servants
Before you can run any CORBA server application in the BEA Tuxedo CORBA environment, you must build it using the buildobjserver command.
Use the buildobjserver -t option to inform the BEA Tuxedo system that the CORBA server application is thread safe. The -t option indicates that the application does not employ shared context data or other programming constructs that are not thread safe. If you run single-threaded applications that are not thread safe in a multithreaded environment, you risk data corruption.
If you update configuration files for an application to enable multithreading support, but the application code has not been updated to indicate that the servant implementation can support reentrancy, note the following:
Note: The SIGKILL signal to terminate a process is supported. The use of SIGIO is not supported in BEA Tuxedo CORBA for single or multithreaded applications.
Creating Reentrant Servants
To create a multithreaded reentrant servant:
If you do create a multithreaded, reentrant servant, the implementation code for that object must protect the state of the object, in order to ensure its integrity while multiple threads interact with it.
Considerations for Client Applications
There are considerations for CORBA client applications running in the BEA Tuxedo environment:
Building and Running the Multithreaded Simpapp Sample Application
This topic includes the following sections:
About the Simpapp Multithreaded Sample
The BEA Tuxedo software provides a multithreaded CORBA sample application, consisting of a client program and a CORBA server program. The server receives an alphabetic string from the client and returns the string in uppercase and lowercase letters. The multithreading capability of simpapp_mt provides parallel processing. Through this parallelism, a single server process can handle concurrent requests from multiple clients for multiple objects or for a single object.
Note: The client application in the simpapp_mt sample is not a multithreaded client application.
How the Sample Application Works
The purpose of a multithreaded server is to handle multiple requests from one or more clients in a parallel manner. The simpapp_mt sample application is a CORBA application that demonstrates multithreading functionality, by using the buildobjserver -t command-line option and using the UBBCONFIG file to specify concurrency strategy.
The simpapp_mt sample first creates a server process named SimplePerObject and secondly a server process named SimplePerRequest. The client communicates first with the SimplePerRequest server and then with the SimplePerObject server.
The thread-per-request server implementation for SimplePerRequest demonstrates the use of a user-defined server class that implements thread initialization methods. The SimplePerRequest server process handles each request from a client in a separate thread of control. Each time a new request arrives, a thread is allocated from the thread pool to handle the request. Once the request has been processed and the reply sent, the thread is released back to the pool. This model is useful for servers that handle long-duration requests from multiple clients.
The simpapp_mt sample application provides an implementation of a CORBA object that has the following methods:
Figure 4-2 shows the operation of the simpapp_mt sample application, employing both the thread-per-object and thread-per-request threading models.
Figure 4-2 simpapp_mt Sample Application
OMG IDL Code for the Simpapp Multithreaded Sample Application The simpapp multithreaded sample application described in this chapter implements the CORBA interfaces listed in the following table.
Listing 4-2 shows the content of the simple.idl file, describing the CORBA interface in the simpapp_mt sample application.
Listing 4-2 OMG IDL Code for the simpapp_mt Sample Application
#pragma prefix "beasys.com"
interface Simple
{
//Convert a string to lower case (return a new string)
string to_lower(in string val);
//Convert a string to upper case (in place)
string to_upper(in string val);
//Use other server to convert string to lower case
string forward_lower(in string val);
//Use other server to convert string to upper case
string forward_upper(in string val);
};
interface SimplePerRequestFactory
{
Simple find_simple();
};
interface SimplePerObjectFactory
{
Simple find_simple();
};
How to Build and Run the Sample Application
This section leads you, step-by-step, through the process of building and running the simpapp_mt sample application. The flowchart summarizes the process and following sections explain how to perform the tasks.
Figure 4-3 Process for Building and Running simpapp_mt
Setting the TUXDIR Environment Variable Before building and running the simpapp_mt sample application, ensure that the TUXDIR environment variable is set on your system. Typically, the environment variable is set during the installation process. You should confirm that the environment variable defines the correct directory location. The TUXDIR environment variable must be set to the directory path where you installed the BEA Tuxedo software. For example: Windows TUXDIR=D:\TUXDIR UNIX TUXDIR=/usr/local/TUXDIR Verifying the TUXDIR Environment Variable Before you run the application, perform the following procedure to ensure that the environment variable contains the correct information. Windows Execute the echo command to show the setting of TUXDIR: prompt> echo %TUXDIR% UNIX
ksh prompt> printenv TUXDIR
Changing the Setting of the Environment Variable
To change the value of the environment variable:
Windows
Execute the set command to set a new value for TUXDIR:
prompt> set TUXDIR=directorypath
UNIX
ksh prompt> export TUXDIR=directorypath
Creating a Working Directory for the Sample Application
Note: The technique of using a work directory is recommended so that you can see what additional files are created when you run the simpapp multithreaded sample. After you execute the runme command, compare the set of files in the installation directory to the set of files in your work directory.
The files required for the simpapp multithreaded sample application are in the following directories:
Windows
%TUXDIR%\samples\corba\simpapp_mt
UNIX
$TUXDIR/samples/corba/simpapp_mt
Create a working directory containing all of the simpapp multithreaded files.
Windows
You can use Windows Explorer to create a copy of the simpapp_mt directory, or you can use the command prompt as follows:
> mkdir work_directory
> copy %TUXDIR%\samples\corba\simpapp_mt\* work_directory
cd work_directory
prompt> dir
makefile.mk simple_per_object_i.h
makefile.nt simple_per_object_server.cpp
Readme.txt simple_per_request_i.cpp
runme.cmd simple_per_request_i.h
runme.ksh simple_per_request_server.cpp
simple.idl simple_per_request_server.h
simple_client.cpp thread_macros.cpp
simple_per_object_i.cpp thread_macros.h
UNIX
You can use your user interface tool to create a copy of the simpapp_mt directory, or you can use the command prompt as follows:
> mkdir work_directory
> cp $TUXDIR/samples/corba/simpapp_mt/* work_directory
cd work_directory
$ ls
makefile.mk simple_per_object_i.h
makefile.nt simple_per_object_server.cpp
Readme.txt simple_per_request_i.cpp
runme.cmd simple_per_request_i.h
runme.ksh simple_per_request_server.cpp
simple.idl simple_per_request_server.h
simple_client.cpp thread_macros.cpp
simple_per_object_i.cpp thread_macros.h
Table 4-1 lists and describes the simpapp_mt files used to build and run the application.
Checking Permissions on All the Files
To build and run the simpapp_mt sample application, you must have user and read permissions on all the files you copied into your working directory. Check the permissions, and change the permissions if required.
Note: Ensure that the make utility is in your path.
Windows
> attrib -R /S *.*
UNIX
> /bin/ksh
> chmod u+r work_directory/*.*
Executing the runme Command
This section describes the steps required to execute the application end-to-end. Enter the runme command as follows:
Windows
> cd work_directory
> ./runme
UNIX
> /bin/ksh
> cd work_directory
> ./runme.ksh
The runme command automates the following steps:
The simpapp_mt sample application prints the following messages while executing the runme command:
Testing simpapp_mt
cleaned up
prepared
built
loaded ubb
booted
ran
shutdown
saved results
PASSED
The entire run-time output for the simpapp_mt sample application is stored in the results directory in your working directory. To see the output created at run time, examine the following files:
Table 4-2 and Table 4-3 identify and describe the files created by executing the runme command.
Running the Sample Application Step-by-Step
This section explains how to run the simpapp_mt sample application in step-by-step mode. You must execute the runme command before running simpapp_mt in step-by-step mode.
Follow the numbered steps to run the simpapp_mt application:
Windows
> ..\results\setenv
UNIX
> ../results/setenv.ksh
>tmboot -y
Booting all admin and server processes in /work_directory/results/tuxconfig
Booting admin processes ...
exec BBL -A : process id=212 ... Started.
Booting server processes ...
exec TMSYSEVT -A : process id=289 ... Started.
exec TMFFNAME -A -- -N -M : process id=297 ... Started.
exec TMFFNAME -A -- -N : process id=233 ... Started.
exec TMFFNAME -A -- -F : process id=265 ... Started.
exec simple_per_object_server -A : process id=116 ... Started.
exec simple_per_request_server -A : process id=127 ... Started.
exec ISL -A -- -n //MrBeaver:2468 : process id=270 ... Started.
7 processes started.
>
Table 4-4 describes the server processes started by tmboot.
Windows
> .\simple_client
UNIX
> ./simple_client
When you execute the client application, messages similar to the following are displayed:
Listing 4-3 Messages Displayed When simpapp_mt Client Is Executed
Number of simultaneous requests to post (1-50)?
String to convert using thread-per-request server?
Sending 4 deferred forward_lower requests
forward_lower request #0 returned:aabbccddeeffgghhiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz
forward_lower request #1 returned:aabbccddeeffgghhiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz
forward_lower request #2 returned:aabbccddeeffgghhiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz
forward_lower request #3 returned:aabbccddeeffgghhiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz
Sending 4 deferred forward_upper requests
forward_upper request #0 returned: AABBCCDDEEFFGGHHIIJJKKLLMMNNOOPPQQRRSSTTUUVVWWXXYYZZ
forward_upper request #1 returned: AABBCCDDEEFFGGHHIIJJKKLLMMNNOOPPQQRRSSTTUUVVWWXXYYZZ
forward_upper request #2 returned: AABBCCDDEEFFGGHHIIJJKKLLMMNNOOPPQQRRSSTTUUVVWWXXYYZZ
forward_upper request #3 returned: AABBCCDDEEFFGGHHIIJJKKLLMMNNOOPPQQRRSSTTUUVVWWXXYYZZ
String to convert using thread-per-object server?
Sending 4 deferred forward_lower requests
forward_lower request #0 returned:aabbccddeeffgghhiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz
forward_lower request #1 returned:aabbccddeeffgghhiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz
forward_lower request #2 returned:aabbccddeeffgghhiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz
forward_lower request #3 returned:aabbccddeeffgghhiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz
Sending 4 deferred forward_upper requests
forward_upper request #0 returned: AABBCCDDEEFFGGHHIIJJKKLLMMNNOOPPQQRRSSTTUUVVWWXXYYZZ
forward_upper request #1 returned: AABBCCDDEEFFGGHHIIJJKKLLMMNNOOPPQQRRSSTTUUVVWWXXYYZZ
forward_upper request #2 returned: AABBCCDDEEFFGGHHIIJJKKLLMMNNOOPPQQRRSSTTUUVVWWXXYYZZ
forward_upper request #3 returned: AABBCCDDEEFFGGHHIIJJKKLLMMNNOOPPQQRRSSTTUUVVWWXXYYZZ
Shutting Down the Sample Application
Before running another sample application, you should shut down the simpapp_mt sample application and eliminate all unwanted files from the working directory.
>tmshutdown -y
Shutting down all admin and server processes in /work_directory/results/tuxconfig
Shutting down server processes ...
Server Id = 5 Group Id = SYS_GRP Machine = SITE1: shutdown succeeded.
Server Id = 2 Group Id = APP_GRP2 Machine = SITE1: shutdown succeeded.
Server Id = 4 Group Id = SYS_GRP Machine = SITE1: shutdown succeeded.
Server Id = 3 Group Id = SYS_GRP Machine = SITE1: shutdown succeeded.
Server Id = 2 Group Id = SYS_GRP Machine = SITE1: shutdown succeeded.
Server Id = 1 Group Id = SYS_GRP Machine = SITE1: shutdown succeeded.
Shutting down admin processes ...
Server Id = 0 Group Id = SITE1 Machine = SITE1: shutdown succeeded.
7 processes stopped.
Windows
> ..\results\setenv
> make -f clean
UNIX
> ../results/setenv.ksh
> make -f makefile.mk clean
Multithreaded CORBA Server Application Administration
This topic includes the following sections:
Specifying Thread Pool Size
The MAXDISPATCHTHREADS and MINDISPATCHTHREADS parameters for specifying the maximum and minimum sizes of the thread pool are in the SERVERS section of the UBBCONFIG file. For examples of how to specify these parameters, see Listing 4-4. A multithreaded CORBA application uses these values to create and manage the thread pool.
MAXDISPATCHTHREADS
The MAXDISPATCHTHREADS parameter determines the maximum number of concurrently dispatched threads that each server process can spawn. When specifying this parameter, consider the following:
Note: If you specify a value greater than 1 for MAXDISPATCHTHREADS and do not supply a value for the CONCURR_STRATEGY threading model parameter, the threading model for the application defaults to thread-per-object. For a discussion of the CONCURR_STRATEGY threading model parameter, see Specifying a Threading Model.
Note: When you build a multithreaded CORBA server application specifying buildobjserver -t, that server is capable of running in multithreaded mode. To run as a multithreaded CORBA server application, the MAXDISPATCHTHREADS parameter in the UBBCONFIG file must be set to a value greater than 1; if it is not, the server application will run in single-threaded mode.
The value of the MAXDISPATCHTHREADS parameter affects other parameters. For example, the MAXACCESSORS parameter controls the number of simultaneous accesses to the BEA Tuxedo system, and each thread counts as one accessor. For a multithreaded server application, you must account for the number of system-managed threads that each server is configured to run. A system-managed thread is a thread that is started and managed by the BEA Tuxedo software, as opposed to threads started and managed by an application. Internally, BEA Tuxedo manages a pool of available system-managed threads. When a client request is received, an available system-managed thread from the thread pool is scheduled to execute the request. When the request is completed, the system-managed thread is returned to the pool of available threads.
For example, if that you have 4 multithreaded servers in your system and each server is configured to run 50 system-managed threads, the accessor requirement for these servers is the sum total of the accessors, calculated as follows:
50 + 50 + 50 + 50 = 200 accessors
MINDISPATCHTHREADS
Use the MINDISPATCHTHREADS parameter to specify the number of server dispatch threads that are started when the server is initially booted. When you specify this parameter, consider the following:
Specifying a Threading Model
To specify a threading model, you set the CONCURR_STRATEGY parameter which is defined in the SERVERS section of the UBBCONFIG file.
Use the CONCURR_STRATEGY parameter to specify the threading model a multithreaded CORBA server application is to use. The CONCURR_STRATEGY parameter accepts either of these values:
When you specify CONCURR_STRATEGY = PER_REQUEST to employ the thread-per-request model, each invocation on the CORBA server application is assigned to an arbitrary thread from the threads pool.
When you specify CONCURR_STRATEGY = PER_OBJECT to employ the thread-per-object model, each active object is associated with a single thread at any one time. Each request for an object establishes an association between a dispatch thread and the object.
If the value for MAXDISPATCHTHREADS is greater than one and you do not specify a value for CONCURR_STRATEGY, the threading model is set to PER_OBJECT.
For more information on the characteristics of threading models, see Threading Models.
Specifying the Number of Active Objects
Use the MAXOBJECTS parameter to specify the maximum number of objects per machine to be accommodated in the Active Object Map tables in the bulletin board. You can set this value in either the RESOURCES section or the MACHINES section of the configuration file. The MAXOBJECTS number in the RESOURCES section is a system-wide setting. Use the MAXOBJECTS number in the MACHINES section to override the system-wide setting on a per-machine basis.
For a system-wide setting, specify:
*RESOURCES
MAXOBJECTS number
To override a system-wide setting for a specific machine, specify:
*MACHINES
MAXOBJECTS = number
The value for number is limited only by the resources of your operating system.
Sample UBBCONFIG File
Listing 4-4 shows a the UBBCONFIG file for the BEA Tuxedo Threads sample application. The threads-related parameters are presented in boldface text.
Note: The value for the MAXOBJECTS parameter affects the operation of a multithreaded server. However, this parameter is not specific to multithreaded servers, since it also affects the operation of single-threaded servers. Increasing the value for MAXOBJECTS results in the consumption of additional system resources for any server.
Listing 4-4 Threads Sample Application UBBCONFIG File
*RESOURCES
IPCKEY 55432
DOMAINID simpapp
MAXOBJECTS 100
MASTER SITE1
MODEL SHM
LDBAL N
*MACHINES
"sunstar"
LMID = SITE1
APPDIR = "/rusers1/lyon/samples/corba/simpapp_mt"
TUXCONFIG = "/rusers1/lyon/samples/corba/simpapp_mt/results/tuxconfig"
TUXDIR = "/usr/local/TUXDIR"
MAXWSCLIENTS = 10
MAXACCESSERS = 200
*GROUPS
SYS_GRP
LMID = SITE1
GRPNO = 1
APP_GRP1
LMID = SITE1
GRPNO = 2
APP_GRP2
LMID = SITE1
GRPNO = 3
*SERVERS
DEFAULT:
RESTART = Y
MAXGEN = 5
TMSYSEVT
SRVGRP = SYS_GRP
SRVID = 1
TMFFNAME
SRVGRP = SYS_GRP
SRVID = 2
CLOPT = "-A -- -N -M"
TMFFNAME
SRVGRP = SYS_GRP
SRVID = 3
CLOPT = "-A -- -N"
TMFFNAME
SRVGRP = SYS_GRP
SRVID = 4
CLOPT = "-A -- -F"
simple_per_object_server
SRVGRP = APP_GRP1
SRVID = 1
MINDISPATCHTHREADS = 10
MAXDISPATCHTHREADS = 100
CONCURR_STRATEGY = PER_OBJECT
RESTART = N
simple_per_request_server
SRVGRP = APP_GRP2
SRVID = 2
MINDISPATCHTHREADS = 10
MAXDISPATCHTHREADS = 100
CONCURR_STRATEGY = PER_REQUEST
RESTART = N
ISL
SRVGRP = SYS_GRP
SRVID = 5
CLOPT = "-A -- -n //sunbstar:2468 -d /dev/tcp"
*SERVICES
![]() |
![]() |
![]() |
|
Copyright © 2001 BEA Systems, Inc. All rights reserved.
|