Corporate Info  |  News  |  Solutions  |  Products  |  Partners  |  Services  |  Events  |  Download  |  How To Buy
	http://www.oracle.com/technology/documentation/index.html   |   Site Map   |   Search   |   PDF Files   |   Contact   |   Glossary
Tuxedo Doc Home   |   Administration   |   Topic List   |   Previous   |   Next   |   Contents

   Setting Up a BEA Tuxedo Application

Sometimes an unexpected system error occurs, freezing a service or causing it to run out of control while it is processing a request. Obviously, it is a good idea to remove these processes, but it is difficult to detect them or determine how they developed errors. The BEA Tuxedo system provides a mechanism for terminating such processes even when you cannot identify them. To use this mechanism, set the SVCTIMEOUT parameter.

The SVCTIMEOUT parameter allows you to designate an amount of time (in seconds) in which a service should be able to process a request. If the interval defined by this parameter elapses and a service has not finished processing a request, the process for that request is killed. In essence, the service timeout mechanism acts like a scavenger for frozen or out of control application servers. By default, the BEA Tuxedo system does not terminate any service process; you must set the SVCTIMEOUT parameter to activate this feature.

You can assign a value to the SVCTIMEOUT parameter in the UBBCONFIG file or by dynamically changing the TA_SVCTIMEOUT attribute in TM_MIB. We recommend that you set the value of SVCTIMEOUT or TA_SVCTIMEOUT to at least two to three times the number of seconds it takes for your longest running service to process a request. Setting the service timeout in this way guarantees that the BEA Tuxedo system removes only frozen processes.

This section describes the causes and results of service timeout errors, and explains how the BEA Tuxedo system reports such errors. Advice about how to handle errors is also provided.

When a timeout occurs, the BEA Tuxedo system terminates the server process running the frozen service (but not its child processes, if any). It then returns a TPESVCERR error, indicating that an unknown problem occurred during processing. In a conversational service, the conversation event TPEV_SVCERR is returned.

The BEA Tuxedo system reports a service timeout through the following three mechanisms:

• TPED_SVCTIMEOUT-timeout error detail that provides more information than tpstrerror(3c)

• .SysServiceTimeout-a system event

• ULOG information about .SysServiceTimeout

Because the SVCTIMEOUT value is configurable, it is important for clients to be able to easily distinguish between a TPESVCERR caused by exceeding the value set for SVCTIMEOUT, and a TPESVCERR caused by other situations. Although the ULOG contains this information, it is difficult for client programs to extract it. To differentiate a service timeout TPESVCERR from others, a program can include a call to the tperrordetail(3c) routine (after a TPESVCERR has been detected), which yields TPED_SVCTIMEOUT when a service timeout occurs.

• Application administrators may control the service timeout by changing the SVCTIMEOUT parameter in the SERVICES section of the UBBCONFIG file, or by modifying the TA_SVCTIMEOUT attribute of the T_SERVER or T_SERVICE class of the TM_MIB. They may also monitor the ULOG file for service timeout activity.

• In addition to monitoring the ULOG file for service timeout activity, application operators can subscribe to the .SysServiceTimeout event, which alerts them when a service timeout occurs.

• Application programmers can use the tperrordetail(3c) and tpstrerrordetail(3c) functions, and the TPED_SVCTIMEOUT error detail code. They may want to add one or more subscriptions to the.SysServiceTimeout system event, which is generated when a service timeout occurs.

Copyright © 2000 BEA Systems, Inc. All rights reserved. Required browser: Netscape 4.0 or higher, or Microsoft Internet Explorer 4.0 or higher.