KB47391: Higher priority jobs do not always take lower priority threads and execute before lower priority jobs when executed in MicroStrategy Intelligence Server

SUMMARY:
This issue has been classified as a defect by Strategy. No current workarounds exist for this issue. This issue affects all reports and documents ran by users on Strategy Intelligence Server. A solution/code fix for this issue is not available in current releases but is being reviewed for a future Strategy release.
 
SYMPTOM:
In order to regulate the order in which jobs execute by the Intelligence server an administrator may set Job Prioritization parameters for a given database instance in Strategy Developer. This is done to ensure that certain jobs are given higher priority than others and that those jobs are run before any others. However, administrators may notice that this is not always the case despite the Job Prioritization parameters set.
 
Consider the following scenario:
 
In Job Prioritization tab for a Database Instance, there are 2 low priority connections and 1 medium priority connection. 

• An entry is created where the Processing Unit Priority for Application Type = Scheduler is set to LOW.  All other values for this entry are set to ALL.
• Another entry is created where the Processing Unit Priority for Group = System Administrators  and Application Type = Scheduler is set to Medium. All other values for this entry are set to ALL.
• The Job Prioritization setup should appear as seen below.                                                                                                                                                                                                                                                                                       

• Some reports are scheduled by users that are not part of the System Administrators group to Schedule A.
• Some additional reports are scheduled by users that ARE part of System Administrators group to Schedule B.
• Schedule A is triggered first and it is seen that all of the reports start running or are waiting in queue, only taking up the 2 threads that were allocated to the low priority jobs. This is as expected.
• Schedule B is then triggered and it is seen that one of the reports that is part of Schedule B starts running on the Medium thread and the remainder wait in queue. This is also as expected.
• However, when one of the reports that was executing on the low priority thread is finished running, It is expected that a report that is part of Schedule B should begin running as it is a medium priority job running, but one of the pending reports from Schedule A begins to run instead and all of the other reports that are part of Schedule B remain pending in the queue.

 
CAUSE:
This issue is caused by the internal Intelligence server pending queue. Although the the jobs from Schedule B are considered higher priority, since the jobs from Schedule A entered the queue first, they will still execute before the higher priority jobs on the lower threads. The Intelligence server will only engage in connection borrowing for higher priority jobs of the lower priority  threads if there is no earlier low priority jobs in the queue waiting. This is a known issue classified as a defect with Strategy Intelligence Server.
 
ACTION:
Currently, this issue is still being reviewed for feasibility by our Technology team and it is not scoped for any upcoming scheduled Strategy release.
 
WORKAROUND:
Currently, the only workaround available to ensure that all higher priority jobs are executed quickly is to increase the number of higher priority threads so that these jobs do not wait in queue for as long or at all.
 
 
ADDITIONAL TROUBLESHOOTING:
If the workaround steps above do not resolve the issue, please consider calling Strategy Technical Support with the following information of troubleshooting already done:

• Screenshots of the Job Prioritization setup.
• Screenshots of the Job Monitor indicating lower priority jobs executing over higher priority jobs.
• Results of following the above workaround.

 
 
The Strategy Internal Reference Number for the issue discussed in this technical note is US31089