Hi Thomas,
I don't think that there are general recommendations that are always valid. It largely depends on the nature of your 
resource manager. Here are some questions that you might want to ask yourself:
- How dynamic is the load on your resource manager expected? Is it a more steady state software where load oscillates 
slightly around some avarage, or do you expect large load peaks, maybe even aperiodically?
- Can you actually handle multiple requests truly in parallel? For instance, if the resource manager needs to access 
some backend storage or hardware to fulfil a task, then a high number of running threads would not help at all if they 
all queue up on a lock on such a resource.
- Is a realtime response to a request necessary, and what is the expected reaction time?

So depending on how the answers look like, here are some properties that I came across:
- W.r.t. realtime, the most critical part is the "increment", because it is evaluated after receiving, but prior (!) to 
handling a message. To be more clear, if the resource manager receives a message, and it finds that the number of 
RECEIVE blocked threads is below lo_water, it creates "increment" new threads prior to calling the handler for the 
message, which can spoil realtime responsiveness.
- If you expect large load peaks AND can truly handle them in parallel AND the handling may enter blocking states other 
than acquiring internal locks, you can set the maximum above 20, so that the bulk work can be done faster.
- Maximum should be well above hi_water, since otherwise the thread pool would need todestroy threads even though there 
are no more threads in RECEIVE blocked state.
- Alternatively, you can create steady-state pools by setting all attributes to the same value if you have rather 
constant load on your resource manager.

W.r.t. resource usage, if the threads use a dynamically allocated stack I think in nowadays systems the resources  used 
by blocked threads weigh less than the resulting speed in software operation.

Hope this helps, just do some experiments and compare behaviour.

Regards,
Albrecht