...
Spawning of the threads is managed by the main thread itself. It will pass important all process parameters to all of the child threads, such as including 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. Thread number also serves purpose during data allocation to each thread.
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 to prevent zombie threads running on the server.
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 preventing long running threads. 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.
Once all child threads have completed their tasks and signaled their finished status, the main thread resumes execution. It collects messages from every child thread, consolidates them, and then writes a message to the }APQ Process Message Response cube. Process messaging concepts are described in chapter Messaging from Backend to Frontend .