Basic Flow of Control for Queued Requests
This section is based on the behavior of the Arbortext Queue Manager and Arbortext Queue that are shipped as part of Arbortext Publishing Engine. A custom queue might implement an entirely different scheme for queuing and processing transactions. A queue manager’s only required behavior is:
• returning a null response if it doesn’t queue a transaction
• returning some kind of response if it does queue the transaction
The basic flow of control for a queued transaction is identical to that of an immediate transaction until the transaction is passed to a queue manager. The Basic Flow of Control for Queued Requests describes what happens in step 3 of
Basic Flow of Control for Request Processing.
1. If the Queue Manager decides to queue the transaction, it passes the transaction to each queue in the order they’re defined in e3config.xml, asking each queue whether it is willing to queue the transaction.
If no queue accepts the transaction, the Queue Manager returns an error response to the
Arbortext PE Request Manager and it continues to the Request Handlers (picking up at step 4 of
Basic Flow of Control for Request Processing).
If the Queue Manager finds a queue willing to accept the transaction, it places the transaction on the queue and sets a response to be returned to the client.
2. Once a transaction is placed on a queue, the queue works with the Queued Transaction Scheduler to determine when the transaction will be processed. The Queued Transaction Scheduler is a daemon thread that awakens periodically and asks each Arbortext PE sub-process pool to allocate an otherwise idle Arbortext PE sub-process. If the allocation request succeeds, the Queued Transaction Scheduler asks each queue whether it has a transaction ready to execute that can run in the Arbortext PE sub-process pool of the allocated Arbortext PE sub-process. If so, the Queued Transaction Scheduler starts the transaction execution. If not, the Queued Transaction Scheduler releases the Arbortext PE sub-process and continues to the next Arbortext PE sub-process pool.
3. To execute a queued transaction, the Queued Transaction Scheduler offers the transaction to each Request Handler in the order they’re defined in e3config.xml.
If a Request Handler accepts the transaction for processing, the request Handler processes the request just as it would if it received a request for immediate processing.
If no Request Handler is willing to take the queued request, the Queued Transaction Scheduler generates an error response for the transaction.
After either of these events, the transaction is marked as complete.
4. Once a queued transaction has been completed, its Transaction Directory contains the same response that would have been returned to the client had the transaction not been queued (an immediate transaction). An HTTP client can retrieve the response by using the web interface or issuing an f=qt-retrieve request. If the response is retrieved, the Arbortext PE Request Manager notes the retrieval.
The transaction directory is deleted from the Arbortext PE server according to which of the following occurs:
◦ If a client retrieves the transaction response, the transaction is deleted after the time indicated by the global parameter com.arbortext.e3.maxRetrievedTransactionAge set in e3config.xml.
◦ If no client retrieves the transaction response, the transaction is deleted after the time indicated by the global parameter com.arbortext.e3.maxCompletedTransactionAge set in e3config.xml.