Use a ThreadPool for RedisMqServer Services instead of hardcoding nbr of threads
For increasing the throughput for a specific Request service in RedisMqServer, you need to manually hardcode the number of threads that the request/service has:
I would like to suggest the option to use a ThreadPool instead.
That would give the option to state the total number of concurrent/parallell processing, but there is no need to lock it down to specific requests. This is more versatile and less resource-wasting; if a certain Service isnt used right now, the threads can be used to process other Services instead.
Maybe something like:
mqService.UseThreadPool = true;
mqService.MaxNbrOfThreads = 50;
The two could be mixed, so if you'd want to dedicate some threads to a Service, then the current syntax could be used:
which would spawn 2 threads, and exclude this service from the ThreadPool usage.
Usage of a dedicated thread per Message Type is per design so throughput can be controlled per Type, sequential processing can be enforced and processing is isolated from long tail of other lower priority MQ Messages delaying processing of higher priority ones.
You can reduce number of sleeping threads by having fewer MQ Types, i.e. combining multiple MQ Tasks into a single union type whose Service implementation can delegate into invoking their different individual services.
Mixing Threadpool MQ Server strategies will not happen with the existing implementation, it requires a completely new implementation with different behavior & design goals.
I’ll leave this feature request open in-case anyone decides to implement a different MQ Server strategy and can post a link to their implementation here.