> > Anytime that you need more than corePoolSize threads, you risk seeing a task > not being executed immediately. > The fact that there is a maximumPoolSize is the bigger issue though. Only > that many total threads can ever be running. If you know enough about all > parts of all services and clients using your River application, you might be > able to accurately guess what maximumPoolSize would need to be. But > ultimately, in a distributed application where circular invocation scenarios > are possible, you need a lot of information and there has to be a lot of > control in the applications to make sure that there are never more than > maximumPoolSize simultaneous method invocations in an instance. > > I don't think that is possible, nor really a good idea to have a > maximumPoolSize. A thread pool design, like TaskManager, where only a > minimum exists, is the type of design we need in River.
Not sure I agree with this. You should _always_ have an upper bound, you cannot assume that you have limitless resources. Just creating threads because an application "says so", is generally not advisable, and can lead to OOME as well as DOS issues.
