Multiple queues #8
Description
What do you think about an abstraction for different queues based on tags or job types?
We are looking into different packages to run our background tasks, but we have a concern about a single queue: Our application has many job types and some of them generate a lot of work that needs to be processed over time. If all jobs are executed from a single queue, we might get into a situation where some service generates a 1000 requests for JobA, and a single requests for JobB will have to wait an indefinite amount of time before there is a thread for it. For some jobs we'd like them to run faster without waiting
I think one solution to that could be internal queues - configurable global queue filters that could have a guaranteed amount of threads out of shared pool to execute filtered jobs in parallel with global queue.
Then, with configuration of 10 threads max parallelism and 1 thread guaranteed to JobB, JobA could be executed in 10 threads, until a request for JobB appears, then it takes 1 released thread, works on it, while JobA keeps processing its 1000 requests in 9 threads until JobB is done.