Arbortext PE sub-process Allocation
There are several ways to allocate an Arbortext PE sub-process. The most common way to allocate an Arbortext PE sub-process follows:
1. A dynamic component makes a call to the com.arbortext.e3.E3RequestContext.allocateE3Subprocess method; the call takes the HTTP request as a parameter. The allocateE3Subprocess method queries every configured Arbortext PE sub-process pool, calling each pool's com.arbortext.e3.E3SubprocessPool.testRequest method. The testRequest determines whether the Arbortext PE sub-processes in that pool are supposed to handle requests like the one specified in the HTTP request.
If the response is true, the subprocess pool attempts to allocate an Arbortext PE sub-process to service the request according to the next steps.
If the answer is false, allocateE3Subprocess continues to query the next Arbortext PE sub-process pool in the list.
2. If a true response is returned for testRequest, then allocateE3Subprocess calls the Arbortext PE sub-process pool's allocate method. The allocate method eventually either returns an Arbortext PE sub-process object or throws an exception after processing the following:
a. The Arbortext PE sub-process pool begins the allocation process by checking for any idle Arbortext PE sub-processes. If so, the one idle for the shortest time is allocated. If not, the Arbortext PE sub-process pool checks whether the configured maximum number of Arbortext PE sub-processes are running. If not, it starts a new one and, when it is ready to accept requests, returns the Arbortext PE sub-process object.
b. If all Arbortext PE sub-processes in the pool are busy and the pool is configured to cascade to another pool, allocate returns the result of the cascaded pool's allocate method.
c. If all
Arbortext PE sub-processes in a pool (and its cascaded pools) are busy and no additional ones can be started, the
allocate method waits until either an
Arbortext PE sub-process is no longer busy or the waiting period expires (explained in
The maxSubprocessWait Attribute). If an
Arbortext PE sub-process is freed during the waiting period,
allocate returns its object.
3. If, after this processing, no Arbortext PE sub-processes are found, allocate throws an exception and transmits an All Arbortext PE sub-processes are currently busy error.
Arbortext PE sub-processes are allocated to process queued transactions by the Queued Transaction Scheduler.
1. The Queued Transaction Scheduler begins by asking an
Arbortext PE sub-process pool for an idle
Arbortext PE sub-process. The
Arbortext PE sub-process pool may start a new
Arbortext PE sub-process if there are fewer than the maximum set by the
maxSubprocesses parameter (see
The minSubprocesses and maxSubprocesses Attributes). However, the scheduler will not wait for a
Arbortext PE sub-process to become free if the maximum number of
Arbortext PE sub-processes are running and none are idle.
2. When the Queued Transaction Scheduler starts the execution of a queued transaction, it associates the allocated Arbortext PE sub-process with the transaction, so that any request to allocate a Arbortext PE sub-process by the queued transaction is satisfied by the transaction that was just allocated. Any attempts to acquire an Arbortext PE sub-process by a queued transaction are ignored. The allocated Arbortext PE sub-process is released by the Queued Transaction Scheduler after the queued transaction finishes executing.
An alternate way to allocate an Arbortext PE sub-process to an immediate request is by using any dynamic component running in the Arbortext PE Request Manager to allocate an Arbortext PE sub-process by querying the list of configured pools directly. The dynamic component can call the pool's allocate method, which bypasses the check for whether a pool should process a particular request. Use this approach with caution.