Troubleshooting Queue Errors on XCOM for Windows.
Article ID: 9381
Updated On:
Products
Issue/Introduction
This document contains background information and a discussion of what parameters can be turned on to improve queue performance.
The queue is designed to keep track of all incoming and outgoing transfers. Each transfer in the queue requires 512 bytes of memory. Each transfer is supplied a unique TID, or Transaction Identifier. If the trace is turned on, all trace information associated with a transfer is identified by the TID and is available for the length of time that the transfer is in the queue. A summary of every transfer is also written in the xcom.log.
Environment
Component:
Resolution
Increasing the Size of the queue
To increase space in the queue, increase the value for the parameter MAX_QUEUE_ENTRIES and/or decrease the value for EXPIRATION_TIME in the XCOM.GLB file in the config subdirectory. Stop and start XCOMD to reload the new parameter values.
What value should I set for MAX_QUEUE_ENTRIES?
This value is the maximum number of transfers that will be need to be held in the queue. This is not the maximum number of concurrent transfers, because transfers are held in the queue after they complete (either successfully or unsuccessfully) until EXPIRATION_TIME passes. At this point, CA XCOM deletes the queue entry and any associated trace files.
You may clear the queue manually by typing xcomqm -R* on the command line. Any transfers waiting to start will need to be resubmitted if you do this. Allow extra entries to account for times when a partner may be down and transfers are held in the queue waiting for the partner to become available again. Also the number of transfers does tend to increase over time, so this number should be reviewed on a regular basis. As the number of transfers in the queue increases, so does the amount of memory used by CA XCOM. The default value is 50. You may raise this value as needed to 500 or higher.
What value should I set for EXPIRATION_TIME?
EXPIRATION_TIME is specified in seconds. Since this value represents the maximum time that the transfer will be held in the queue after the transfer is complete, you need to consider why you need to retain a transfer after it is finished. One reason for retaining a TID is to access the associated trace information. There is also detailed information regarding each specific transfer accessible through the XCOM APIs, from the command line or from the GUI Status Window which is accessible by clicking on the Queue Manager button. If most of your transfers are handled automatically or at off-peak hours, then this information may be extraneous because each transfer will have information regarding its status recorded in the xcom.log.
It is also important to realize that as this value is reduced, the associated TID's become free and therefore the same number of entries can handle more transfers. This is particularly true if EXPIRATION_TIME is reduced drastically and the transfers are sent in a steady continuous pattern. Reducing the EXPIRATION_TIME may be necessary if you need to dramatically increase the value of MAX_QUEUE_ENTRIES. If you do not need to access information about completed transfers in the queue, you may set EXPIRATION_TIME as low as 1, raising it temporarily if you need to troubleshoot. The transfer information will still be available in the xcom.log.
Why would I have these problems intermittently?
CA XCOM continuously deletes completed entries from the queue based on EXPIRATION_TIME. So a problem with queuing will usually resolve itself with no manual intervention if fewer transfers are being sent and received. This is not a permanent solution, however.
Decreasing Overhead and Contention in the Queue
Raise the value for STAT_FREQUENCY in xcom.glb to 25 or greater. The default value is 10. STAT_FREQUENCY specifies the number of records (or blocks, if using packing) that are sent or received before the queue files get updated. A low value causes the queue files to get updated more often. This allows the Queue Status window to get updated frequently but also increases the contention on the queue files.
A high value causes the queue files to get updated less often and the Queue Status window may be a bit behind in displaying the current status of a transfer. However, this also reduces some of the contention on the queue files and can also increase transfer performance, as the overhead of extra updates to the queue files are removed.
NOTE: Always stop and start xcomd after making changes to xcom.glb.
Feedback
