So can FJP; or TPE, for that matter

Not in the same manner. An injector literally manages multiple ExecutorService instances. You get an InjectionExecutor from an Injector. This means the concurrency and queueing aspects of each SEDA stage are still managed independently, but the thread management costs are shared. FJP or a TPE would have a shared queue and thread limit for all of the stages, which could lead to some very problematic characteristics, depending on your goals.

Do you mean Injector handles external submissions better than FJP?

Yes. Specifically external submissions when the executor is not fully occupied by existing tasks, or when the tasks being submitted are very short (shorter than thread signalling time * number of cores). Once the executor is saturated both behave very similarly, but in a typical application server/SEDA architecture the goal is to process work faster than it can accumulate, which means regularly exhausting the outstanding work. Otherwise your work will likely grow unbounded and you'll fail to meet your service SLAs. Optimising this submission scenario leads to significant wins in such systems, and is precisely what the injector is designed to achieve.

Disruptor has a lot of contention

It depends on how you define contention. The costs of queueing/dequeueing are really very low in absolute terms. Your work has to be very cheap indeed for it to be a significant factor. But you're right, and I was careless in my assertion: if you have very little external submission and your executor is saturated (all threads occupied), the disruptor is slower than FJP. If you have any significant external quantity (doesn't likely need to be most), or you regularly catch up with the rate of work provision (and you have threads <= cores) then the disruptor is likely faster (though may burn more cpu).

and consumers that block

The disruptor really was not designed for this case. We're moving back into territory where you need more threads than cores, and we're back to where the injector wins. FJP is generally much better than the disruptor in this scenario, since it also handles threads >> cores significantly better than the disruptor does. The disruptor is really very bad at handling these workloads.

I should clarify that when I say threads >> cores, I mean the total number of application threads, not just the number of threads in the pool.

Generally: * FJP is for primarily internal submissions, and the executor is fully saturated. * Injector is primarily for external submissions, or where the executor is not regularly saturated. * Disruptor is primarily for where there are fewer threads than cores. If this criteria is met, the only time it is likely beaten is in FJP's main goal territory: fully saturated internal submissions.

I contend that the Injector matches the criteria of more application servers than FJP or Disruptor.