Work Manager Is Not A Thread Pool Max Threads Constraint Is

Sharing Max Threads Constraint between multiple Work Managers causes them to share the same thread pool.

It is natural to think of a Work Manager as a thread pool, and of Max Threads Constraint as a property of that pool.

Therefore it is natural to create, say, 3 Work Managers and assign each of them a Max Thread Constraint of 30 – the same named constraint (e.g. “MaxThreads30”).

The problem is that it’s wrong.

In fact, the Max Threads Constraint is a thread pool.

When you share the same Max Thread Constraint between 3 Work Managers, you do not get 3 pools of 30 threads each. You get one pool of 30 threads shared between those 3 Work Managers.

Then, when you assign those 3 Work Managers to 3 proxies as dispatch policies, everything works… until the peak traffic comes. Then the services begin to rob each other of the threads, suffocating from the lack of CPU given to them.

It gets even worse when one of the services becomes slow, consuming all 30 threads from the pool, and the 2 others experience DoS because there are no threads left for them at all.

Solution?

Easy: for each Work Manager you create, also make a dedicated Max Threads Constraint.

P.S. What about Min Threads Constraint? Apparently, it does nothing. We were unable to find any effect on the services behaviour it has. We just do not create Min Threads Constraint in our domains.