Recommendation - Managing Long-Running or Resource-Intensive Tasks
Read this section to learn how to take advantage of the built-in capabilities of the monitor service (monitorService) to manage queues for all server instances.
You should follow this recommendation if you have tasks that are either long-running, system-resource intensive, or both, and you wish to ensure that your tasks do not interfere with the pre-configured load-balancing and queue management functionality of IBM® Cognos®.
Call the monitorService instead of a target service to allow the monitor service to manage tasks across dispatchers. You can specify the background option in the request if you do not wish to maintain the asynchronous conversation in your application.
The monitor service monitors activity to determine the capacity of services managed by a dispatcher to process requests.
A request is sent to the dispatcher from the application queue based on activity information collected by the monitorService in order to maximize the use of resources. For example, if a service instance that belongs to dispatcher "A" has more available capacity than an instance that belongs to dispatcher "B", the monitorService forwards the request to dispatcher "A".
If you send a request directly to a service, you cannot take advantage of this functionality and the monitor service is normally not involved in managing the request. The dispatcher instance for the target service still has its own queue management and basic load-balancing, but it is local to that dispatcher instance only. As a result, resources may not be used as effectively as they could be.
Advantages of calling the monitor service directly include the following:
The monitor service queues your request and forwards it to a target service with available capacity. If a server or the target service fails, the request is maintained in the queue and can be re-submitted.
Disadvantages of calling the monitor service directly include the following:
Creating a large number of bibus » history objects can be resource intensive.
For example, if you run a large number of small reports, each run request requires that a bibus » history object be created.
Your request may not be processed as quickly.
Passing your request directly to the monitor service instead of the target service requires an additional processing step as well as additional communications with the content store to create a bibus » history object. This may not always be more efficient if the available services are performing at capacity, or if there is only one service instance that can satisfy the request.
Advantages of calling the target service directly include the following:
Your request may be processed more quickly.
The overhead of creating a bibus » history object is avoided, if a bibus » history object or the ability to re-submit a failed request is not required.
Disadvantages of calling the target service directly include the following:
System resources may not be fully utilized as the load-balancing functionality of the monitor service is not being taken advantage of.
Overall performance could be affected as the request cannot be managed beyond the target service's local dispatcher.
A bibus » history object may not be created, depending on the type of request. Without a bibus » history object, the task cannot be re-submitted if a system or service failure occurs.
For more information about retrying failed tasks, see Retrying Tasks.