Currently the scenario is such that if a refresh is scheduled manually, it takes up the highest priority and occupies the backgrounder processes when free. The situation becomes dire if the manual extracts are actually low priority jobs but run for a long period of time. In order to avoid a situation where a high priority Scheduled extract
- gets delayed due to manual extracts which run for long and
- gets continuously pushed back in the queue due to new manual extracts being triggered by users
The only way to avoid such a scenario would be to manually kill the process as described here Stopping a 9.x Tableau Server Background Task (Windows) by Toby Erkson
To avoid this manual intervention as much as possible, I would like to propose the following idea.
1. Allow a server admin to set a specific number of backgrounder processes which can be utilized for manual extracts, while making available all backgrounder process for scheduled extracts.
To elaborate further, assuming I have 4 backgrounder processes, I would like to set only 2 backgrounder process queues to be utilized for all manually triggered refreshes. However, in case of scheduled extracts, any of the 4 backgrounder processes can be utilized depending on availability.
As an additional feature, it would be nice to allow a server admin to also specify backgrounder processes dedicated to high priority scheduled jobs (specify priority range) to ensure that these jobs are always run/process is available when triggered.
2. Allow a server admin to determine which users can manually trigger extract refresh. This could be described in the permissions pane for each user. ( perhaps on the project level? )