As an aside, I’ve been asked when I’ve discussed this topic at EUGs “why three? why not 39 or 10 or X?”
I’ll tell two potentially fictional versions of this story, and I’ll let you dear audience decide which one you prefer.
THE LORE OF THREE TASK AGENTS VERSION 1:
When this functionality was being designed, we wanted to make sure that we chose a useful and technically practical limit. We knew we wanted more than one which was the previous limit.
We then reviewed our largest customer’s infrastructure at 10.0–our two largest customers in terms of total user count were both Epicor; one was our MT Cloud offering (which for this conversation we are calling Epicor because in many ways, they function like one very large internal customer instead of many smaller external ones) and the other was our own corporate usage of it. It seemed that the Operational people determined that three background processing appservers seemed to be the sweet spot and that is what they were already using. It only made sense to allow for at least three because that is essentially what our two largest customers were trying to accomplish.
We completed some internal testing to see what the upper practical limit was based on our initial engineering of this (basically, push it until something breaks), we noticed that as the number of taskagent configurations increased some crazy impractically large number to some much crazier impractically larger number, locking/blocking could occur with many taskagent configurations all vying to see which one can stake claim to a particular request first because each taskagent configuration is independent from the others and has no awareness of others – each taskagent configuration just polls every X number of seconds based on the processing delay set on the system agent).
We could have spent a little time reengineering the process to allow for more than a much larger crazier number of taskagent configurations, but, the intent was to simply prevent an outage of background processing and not as a performance improving measure because having more taskagents will not improve background processing performance. After a full testing regimen at three taskagent configurations, we determined that for what we were trying to accomplish (to prevent the taskagent from being a single point of failure) having more than that wouldn’t be beneficial towards that goal.
As we are now three releases into this change (10.1.400, 10.1.500, and very soon 10.1.600) this design choice was validated based on actual experience that three taskagents for even our largest customers is not a limitation in practice. If three is enough for thousands of concurrent users we feel it should meet the needs for those with fewer. As I mentioned in the original post, this change was introduced as a way of preventing the taskagent configuration itself from being a single point of failure if something unforeseen happens not as a way of ignoring the problem that caused the outage itself.
THE LORE OF THREE TASK AGENTS VERSION 2:
Three is more than one and less than five, and due to an innate cognitive aesthetic preference for odd numbers, we settled on three instead of four.