Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

Main thread of a TI process serves two purposes. It spawns child threads and once spawned it starts to monitor the child threads and wait until all child threads have finished.

Spawning of the threads is managed by the main thread itself. It will pass important parameters to all of the child threads, such as the dimension for parallelization, the total count of threads (including the main thread), and the unique thread number. The main thread always has a thread ID of 0, while child threads are assigned numbers starting from 1.

Monitoring of the threads runs in two phases, first during the initiation of the child threads and second during their execution. The main thread watches for timeouts during both phases.

The main thread has the option to participate in data processing. However, doing so might compromise its capability to identify time out scenarios. This is because the main thread itself could time out, preventing it from accessing the code that oversees the child threads. This option is configurable in the }APQ Settings cube.

Monitoring during initiation phase of child threads allows for quicker identification of failures that might happen in prolog code of the TI process. These issues might be caused for example by invalid data source or by a slowly performing view. The timeout for this phase is configurable in }APQ Settings cube.

Monitoring during execution of the child threads will allow to detect situation when data processing (metadata, data or epilog) is not able to finish in timely fashion. The timeout for thread execution is configurable in }APQ Settings cube.

Monitoring of both above phases is performed by thread status polling method described below.

The main thread waits till all child threads have finished their processing and have signalled completed status. Then it continues in its execution to collect messages from all child threads and to consolidate them into one message that will be written into }APQ Process Message Response cube. Process messaging concepts are described in chapter Messaging from Backend to Frontend .

  • No labels