|
|
|
|
|
|
Maintenance of the BEA Tuxedo /Q Feature
This topic covers some things the queue administrator may have to do from time to time to keep a queue space operating efficiently.
Adding Extents to a Queue Space
If you find you need more disk storage for a queue space, you can add it with the qaddext command of qmadmin(1). (You can also use the TA_MAXPAGES attribute of the T_APPQSPACE class of APPQ_MIB(5) to add extents.) The qmadmin command takes the queue space name and a number of pages as arguments. The pages come from extents defined in the UDL for the device in your QMCONFIG variable. The queue space must be inactive; you can use the exclamation point to execute a command outside of qmadmin to shut down the associated server group. For example:
> !tmshutdown -g TMQUEUEGRP1
followed by
> qclose
> qaddext myqueue 100
The queue space must be closed; qmadmin closes it for you if you try to add extents to it while it is open. All non-persistent messages currently in the queue space are lost when the qaddext command is issued and completes successfully.
Backing Up or Moving Queue Space
A convenient command to use to back up a queue space is the UNIX command dd. Shut down the associated server group first. The command lines would look like this:
tmshutdown -g TMQUEUEGRP1
dd if=<qspace_device_file> of=<output_device_filename>
For other options, see dd(1) in a UNIX system reference manual.
This same command can be used to migrate the queue space to a machine of the same architecture, although you may need to start the command sequence with a qmadmin chdl command to provide a new device name if the present name does not exist on the target machine.
Similar archival techniques are available on server platforms that do not have the dd command. First, shut down the group containing the queue space you want to back up or migrate. Then, use an archival tool to save the queue space device to a file or other medium that may then be used as a back up or used to move the queue space to another server.
Moving the Queue Space to a Different Type of Machine
If you need to move a queue space to a machine with a different architecture (primarily byte order), the procedure is more complex. Create and run an application program to dequeue all messages from all queues in the queue space and write them out in machine-independent format. Then enqueue the messages in the new queue space.
TMQFORWARD and Non-Global Transactions
Messages dequeued and forwarded using TMQFORWARD are executed within a global transaction because the operation crosses group boundaries. If the messages are executed by servers that are not associated with an RM or that do not run within a global transaction, they should have a server group with TMSNAME=TMS (for the NULL XA interface).
TMQFORWARD and Commit Control
The global transaction begun by TMQFORWARD when it dequeues a message for execution is terminated by a tpcommit(). The administrator can set the CMTRET parameter in the configuration file to control whether the transaction commits when it is logged or when it is complete. (See the discussion of CMTRET in the RESOURCES section of the UBBCONFIG(5) reference page.)
Handling Transaction Timeout
Handling transaction timeout requires cooperation between the queue administrator and the programmer developing client programs that dequeue messages. When tpdequeue(3c) is called with the flags argument set to include TPQWAIT, the TMQUEUE server will wait for a message to arrive on a queue before returning to the caller. The number of seconds before it times out is based on the following:
If a message is not immediately available when using TPQWAIT, TMQUEUE requires an action resource so that TMQUEUE may service other requests. You may want to increase the number of actions the queue space may handle concurrently. Use the -A actions option to the qspacecreate or qspacechange commands. This option specifies the number of additional actions that can be handled concurrently. When a waiting operation is encountered and additional actions are available, the blocking operation is set aside until it can be satisfied. If no actions are available, the call to tpdequeue fails.
TMQFORWARD and Retries for an Unavailable Service
When a TMQFORWARD server attempts to forward messages to a service that is not available, the situation can develop where the retry limit for the queue may be reached. The message is then moved to the error queue (if one exists). To avoid this situation the administrator should either shut the TMQFORWARD server down or set the retry count higher.
When a message is moved to the error queue it is no longer associated with the original queue. If errors are going to be handled by the administrator moving the message back to the service queue when the service is known to be available, then the queue name may be stored as part of the corrid in the TPQCTL structure so the queue name is associated with the message.
|
|
|
|
|
|
Copyright © 2000 BEA Systems, Inc. All rights reserved.
|