Concurrent processing uses the Output Post Processor (OPP) to enforce post-processing
actions for concurrent requests.
Post-processing actions are actions taken on concurrent
request output. An example of a post-processing action is that used in publishing
concurrent requests with XML Publisher.
For example, say a request is submitted with
an XML Publisher template specified as a layout for the concurrent request output.
After the concurrent manager finishes running the concurrent program, it will contact
the OPP to apply the XML Publisher template and create the final output.
A concurrent manager contacts an available OPP process when a running concurrent
request needs an OPP processing action. A concurrent manager uses a local OPP
process (that, is, on the same node) by default, but will choose a remote OPP if no local
OPP process is available.
There should always be at least one OPP process active in the system. If no OPP service
is available, completed requests that require OPP processing will complete with a status
of Warning.
An OPP service is multi-threaded and will start a new thread for each concurrent
request it processes. You can control the number of simultaneous threads for an OPP
service instance by adjusting the Threads per Process parameter for the instance.
If all the OPP services have reached their respective maximum number of threads, the
requests waiting to be processed remain in a queue to be processed as soon as threads
become available.
If request throughput has become slow, you may want to increase the
number of threads per process for the OPP. It is recommended that you keep the
number of threads per process between 1 and 20.
actions for concurrent requests.
Post-processing actions are actions taken on concurrent
request output. An example of a post-processing action is that used in publishing
concurrent requests with XML Publisher.
For example, say a request is submitted with
an XML Publisher template specified as a layout for the concurrent request output.
After the concurrent manager finishes running the concurrent program, it will contact
the OPP to apply the XML Publisher template and create the final output.
A concurrent manager contacts an available OPP process when a running concurrent
request needs an OPP processing action. A concurrent manager uses a local OPP
process (that, is, on the same node) by default, but will choose a remote OPP if no local
OPP process is available.
There should always be at least one OPP process active in the system. If no OPP service
is available, completed requests that require OPP processing will complete with a status
of Warning.
An OPP service is multi-threaded and will start a new thread for each concurrent
request it processes. You can control the number of simultaneous threads for an OPP
service instance by adjusting the Threads per Process parameter for the instance.
If all the OPP services have reached their respective maximum number of threads, the
requests waiting to be processed remain in a queue to be processed as soon as threads
become available.
If request throughput has become slow, you may want to increase the
number of threads per process for the OPP. It is recommended that you keep the
number of threads per process between 1 and 20.
No comments:
Post a Comment