I’m using the great MQ features of ServiceStack more and more, but I’m a bit worried about the scalability; from your docs, each DTO listener requires a minimum of 2 threads per server. As I roll out new features that are “long running”, this thread overhead grows. Is there any plans or ability to react to these from a shared pool or are you limited by the way Redis Messaging works?
Having said this, I can’t find out how many threads an Azure web site app has access to, so may be worrying about nothing.
You can disable the priorityq’s so each message only needs a minimum of 1 background thread per Request DTO that you’ve explicitly registered with the MQ Service. The threads are sleeping when they’re not in use so they’re not using up CPU or generating any lock contention. You can use ThreadPool.GetMaxThreads() to view number of maximum ThreadPool threads.
There’s no plan on changing how all the MQ Servers work. If you’ve discovered any scalability issue I’d like to know about it.