When you start a Burst or Schedule the “runtime” engine behind the scenes springs into life to co-ordinate all of the separate tasks that will be required to run and deliver your reports.
Each Burst within a Schedule is broken down into a series of requests, each of which is allocated to a processing Queue so that InfoBurst can throttle a large number of requests that are all made at the same time.
Bursts can be configured to run in a number of ways, either sequentially or in parallel and the resulting deliveries can either be done at the end or per document when content is available.
Once a request is allocated to a Queue and there is capacity available it will start running and InfoBurst will keep an eye on it to make sure it does not exceed any given time threshold (and if it does it will kill and restart the task).
Over the past year several large customers have been pushing the limits of what the runtime can handle and we have been making some core changes to both improve the throughput and the reliability when faced with tasks that abort or hang (especially when using the parallel processing mode).
The goal of the runtime is to run all tasks as quickly as possible and be able to recover if things go wrong so that there is no interruption of service.
Build 128 is a significant step forwards for the runtime and if you are a high volume site we would strongly recommend?an upgrade to this build.
