[Top] [Prev] [Next] [Bottom]

2. BEA TUXEDO System Workstation Administration


What This Chapter Is About

This chapter describes the administration issues for BEA TUXEDO system applications that use the Workstation feature. The administration of Workstation clients, Workstation handlers, and the listener are all performed in the BEA TUXEDO system administrative domain, not at the workstation. The issues discussed here are Workstation specific; they do not include topics such as client naming and authentication that apply to native clients as well as Workstation clients. For a complete discussion of BEA TUXEDO system application administration, please refer to Administering the BEA TUXEDO System.

Issues covered here include:

Configuring BEA TUXEDO Workstation

The UBBCONFIG file contains important Workstation parameters in the RESOURCES and MACHINES sections. The Workstation listener is defined as a system-supplied server in the SERVERS section, with a reference to an entry in the GROUPS section. We will examine the pertinent sections in the order in which they appear in the configuration file.

RESOURCES Section and MACHINES Section

The MAXWSCLIENTS parameter can be specified in the MACHINES section of the configuration file to apply to specific machines. MAXWSCLIENTS is the only parameter that has special significance for Workstation. If MAXWSCLIENTS is not specified, the default is 0.

MAXWSCLIENTS

The MAXWSCLIENTS parameter tells the BEA TUXEDO system, at boot time, how many accesser slots to reserve exclusively for workstation clients. For native clients, each accesser slot requires one semaphore. However, the Workstation handler process (executing on the native platform on behalf of workstation clients) multiplexes Workstation client accesses through a single accesser slot, and therefore requires only one semaphore. This points out an additional benefit of the Workstation extension. By putting more clients out on workstations and off the native platform, an application reduces its IPC resource requirements. To repeat, although MAXWSCLIENTS is optional, if not specified, the default is 0.

MAXWSCLIENTS takes its specified number of accesser slots from the total set in MAXACCESSERS. This is important to remember when specifying MAXWSCLIENTS; enough slots must be left to accommodate native clients as well as servers. If you specify a value for MAXWSCLIENTS greater than MAXACCESSERS, native clients and servers will fail at tpinit() time.

GROUPS Section

A GROUPS section entry is required for the group that includes the Workstation listener; the listener need not be the only member of the group. The GROUPNAME is a name selected by the application. The following two parameters must be specified for each entry:

LMID = identifier [,identifier]
The identifier(s) given as the value of the LMID parameter must be among those specified in the MACHINES section.

GRPNO = number
The value is a number between 1 and 30,000 and must be unique among all entries in the GROUPS section.

No other parameters of the GROUPS section need be specified for the group that includes the Workstation listener; in fact, none of the other parameters make any sense for the listener. If you choose, you can specify other servers in the group, but we recommend that you do not include any that expect to open a resource manager.

SERVERS Section

Workstation clients access your application through the services of:

The Workstation listener (WSL) and Workstation handler (WSH) are specified in one entry as a BEA TUXEDO system-supplied server, although they are separate processes. The WSL can support multiple Workstation clients. It acts as the single point of contact for all the Workstation clients that connect to your application at the network address specified on the WSL command line. The listener schedules work for one or more Workstation handler processes. A Workstation handler process acts as a surrogate within the administrative domain of your application for clients on remote workstations. The WSH uses a multiplexing scheme to support multiple Workstation clients concurrently.

The tag, or AOUT, value for a Workstation listener entry in the SERVERS section is WSL.

Each entry must have the following parameters:

SRVGRP = groupname
this will be the previously defined GROUPNAME value from the GROUPS section.

SRVID = number
is a number between 1 and 30,000 that identifies a server within its group.

CLOPT = options
are the command line options for the WSL. They are described in the section that follows and also on the WSL(5) reference page in the BEA TUXEDO Reference Manual.

Other SERVERS section parameters that are useful for WSL entries are:

SEQUENCE = number
gives control over the order in which servers are booted (also used by tmshutdown).

RESTART = {Y|N}
should be specified as Y to permit restarts.

GRACE = number
should be specified as 0 to permit an infinite number of restarts.

Other optional SERVERS parameters are described in ubbconfig(5).

Workstation Client Timeout

In earlier releases (prior to v6.4), the loss of a network connection (because of a problem in the network, the WSH, or the server) caused another problem from which it was hard to recover: the application would hang indefinitely, while the client waited for a response from the WSH. This problem was not limited to API calls that received data, such as tpgetreply(3c) or tprecv(3c). It occurred in all API calls to the WSH except tpbegin(3c), and in function calls for buffer allocation.

The current release provides two administrative options to WSL that enable you to avoid this problem. Specifically, these options allow you to:

With these features, you can ensure that the WSH client no longer hangs indefinitely when a network connection is lost.

This section describes these features and provides instructions for using them.

The Keep-alive Option

Keep-alive is a networking operation that periodically checks the viability of a network connection between WSH and a workstation client if no traffic has occurred over that connection within a period of time specified by the operating system.

How Keep-alive Works

You can request the keep-alive operation through a new administrative option to the WSL: -K. This option improves the speed and reliability of detection of a network failure, by actively testing the state of an idle connection at the protocol stack level. The -K option can be set to client, handler, both, or none.

Limitations

The keep-alive operation is supported only on platforms on which the BEA TUXEDO system uses sockets:

You cannot use this option on any other platform. The BEA TUXEDO system lets you specify the -K option for any server machine, but it will not execute it properly on any platform other than those previously listed. If you try to perform a keep-alive operation on any other platform, your attempt fails and a message is written to the userlog (once per process for the WSH). Processing continues normally:

How to Use Keep-alive

To use the keep-alive operation in your BEA TUXEDO application, edit the UBBCONFIG file as follows.

  1. Open your UBBCONFIG file.

  2. Go to the SERVERS section.

  3. Find your entry for WSL.

  4. To the CLOPT argument, add the -K option, followed by one of four valid arguments: client, handler, both, or none (the default).

    To Activate Keep-alive for Select

    The Workstation client

    client

    The Workstation Handler

    handler

    Both the client and the handler

    both

    Neither the client nor the handler

    none (the default)

Your entry in the UBBCONFIG file should look like the following.

WSL SRVGRP="WSLGRP" SRVID=1000 RESTART=Y GRACE=0 
CLOPT="-A -- -n 0x0002ffffaaaaaaaa -d /dev/tcp -K both"

In the example, -K turns on the KEEPALIVE checking on both the Workstation client and the server side.

For details about the format of a WSL entry in UBBCONFIG, see WSL(5) in the BEA TUXEDO Reference Manual.

Note: Any timeout period that you specify applies to the entire system. Remember that if, with one application in mind, you later change the amount of time specified, any other application that uses keep-alive is also affected.

The Network Timeout Option

Network timeout is an option that lets you decide how long you are willing to wait for an operation in a Workstation client before your request for that operation is cancelled (times out) on a network.

You can request the network timeout function through an administrative option to the WSL: -N. The -N option uses a network timeout to receive data in the Workstation client.

How Network Timeout Works

The network timeout option establishes a waiting period (in seconds) for any BEA TUXEDO operation in the Workstation client that receives data from the network. If the period is exceeded, the operation fails and the client is disconnected from the application. A value of 0 (the default) indicates no timeout.

Note: Setting this value too low may cause too many disconnects.

Each ATMI call returns an error whenever a timeout occurs. When a link times out, the application is notified. An existing error code is used. (Additional error detail on the specific error can be retrieved by a call to tperrordetail(3c)). Once a network timeout occurs, the status of outstanding operations is in doubt: transactions cannot be completed; incoming replies can be lost, and so on. The only safe action is to terminate the connection to the application by doing the equivalent of a tpterm(3c) without communicating with the WSH.

By the time the operation returns, the client is no longer part of the BEA TUXEDO application. The application can rejoin the application in either of two ways:

Limitations

How to Use Network Timeout

To use the network timeout function in your BEA TUXEDO application, edit the UBBCONFIG file as follows.

  1. Open your UBBCONFIG file.

  2. Go to the SERVERS section.

  3. Find your entry for WSL.

  4. To the WSL CLOPT argument, add the -N option.

The WSL CLOPT Parameter

The command-line options specified via the CLOPT parameter tell the system:

Figure 2-1 illustrates the relationship between Workstation clients and the support processes on the machine serving as the administrative domain. The words in parentheses are substitutables in the command line options of the WSL or server entry parameters.

Figure 2-1 BEA TUXEDO Workstation Feature: Support Processes

The format of the CLOPT parameter is as follows:

CLOPT="[-A] [servopts options] - - -n netaddr [-d device] \
[-w
WSHname] [-t timeout-factor] [-T client-timeout] \
[-m
minh] [-M maxh] [-x mpx-factor] \
[-p
minwshport] [-P maxwshport] \
[-I
init-timeout] [-c compression-threshold] [-k compression-threshold] \
[-z
bits] [-Z bits] [-H external_netaddr] [-K {client|handler|both|none}]"

As noted above, the -A value indicates that the WSL is to be booted offering all its services. This is a default, but it is shown in the example to emphasize the distinction between system-supplied servers and application servers. The latter may be booted offering only a subset of their available services.

The -- syntax marks the beginning of parameters that are passed to the WSL after it has been booted.

The -n netaddr Option

This is required. netaddr is the network address used by Workstation clients to connect to your application. The Workstation listener process uses this address to listen for clients attempting to connect at this address.

The -d device Option

The value of device is the device name used by the Workstation listener to access the network. In the past this option was required if the transport provider was TCP/IP. As of BEA TUXEDO Release 6.4, this option is no longer required.

The -w WSHname Option

WSHname is the name of the Workstation handler process started by the Workstation listener. You should specify the name of the executable created by buildwsh(1). The default name assumed for that a.out is WSH, the Workstation handler that is delivered with Workstation. That name is used if the -w option is omitted. If you customize a Workstation handler, make certain that it resides in either $APPDIR or $TUXDIR/bin. If your customized Workstation handler is used by only one application, we recommend putting the handler in the directory specified by the APPDIR environment variable. If the handler is used by many applications, we recommend putting it in the bin directory under $TUXDIR.

The -t timeout-factor Option

When a large number of workstation clients attempt to connect simultaneously, some of the requests may time out due to a blocking condition. The -t timeout-factor is provided to guard against this possibility. The value of timeout-factor is a number that, when multiplied by SCANUNIT, specifies the amount of time in seconds that should be allowed for a workstation client to complete initialization processing through the WSH before being timed out by the WSL. The default for this parameter is 3 in a non-security application, and 6 in a security application.

The -T client-timeout Option

Client-timeout is the amount of time (in minutes) that a client is allowed to stay idle. If a client does not make any requests within this time period, the WSH disconnects the client. If this argument is not given or is set to 0, then the timeout is infinite.

The -m minh Option

The minh value is the minimum number of Workstation handler processes to be started by this Workstation listener when the listener is booted. If specified, the -m option takes a value from 0 to 255. The default is 0.

The -M maxh Option

maxh is the maximum number of Workstation handler processes to be started by this Workstation listener. If specified, the -M option takes a value from 1 to 32,767. The default is MAXWSCLIENTS for the machine divided by the multiplexing factor MPX. For example, let's say you specify MAXWSCLIENTS=100 in the MACHINES section and -x10 for the CLOPT of the listener. The default for -M maxh is 100/10 or 10. maxh must be greater than or equal to minh.

The -x mpx-factor Option

The mpx-factor value specifies the number of Workstation clients you want each Workstation handler to support simultaneously. If specified, the -x option takes a value from 1 to 32,767. The default is 10.

The -K { client | handler | both | none } Option

Use -K to turn on the network keep-alive operation for the client, the handler, or both. You can turn off this option for both the client and handler by specifying none.

Example

The entries related to Workstation as specified in the configuration file for the bankapp application are shown in Listing 2-1.

Listing 2-1 Excerpts from bankapp configuration file
#
# ubbconfig file for Workstation example, SHM mode
#
"mach1" LMID="SITE1"
TUXCONFIG="/tuxroot/tuxapp/tuxconfig"
TUXDIR="/tuxroot"
APPDIR="/tuxroot/tuxapp"
TLOGDEVICE="/tuxroot/tuxapp/TLOG"
TLOGNAME="TLOG"
TLOGSIZE=100
MAXACCESSERS=100
MAXWSCLIENTS=50
#
*GROUPS
"GRP1" LMID="SITE1" GRPNO=4
#
*SERVERS
"WSL" SRVGRP="GRP1" SRVID=2
CLOPT=" - -n //wsl.beasys.com:3107 -d /dev/tcp"
RQPERM=0660 REPLYQ=Y RPPERM=0660
MIN=1 MAX=1 CONV=N
SYSTEM_ACCESS=FASTPATH
MAXGEN=5 GRACE=86400 RESTART=Y
#



[Top] [Prev] [Next] [Bottom]