I am going to reply to some of these again/more in depth now that I am back at
my computer keyboard.
Comments below.
Dennis Reedy wrote:
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.
I won't deny this is an issue. The bigger problem, is the fact that TaskManager
is used to create threads for inbound calls. If you have all of River running
inside of a single Java process, each river service started under
ServiceStarter, each one will have its own instance of TaskManager with it's own
parameterization.
The problem, is how can you possibly know which inbound call is the right one to
allow in and which ones should not be allowed in? Which are going to commit the
transaction, or add the object to the javaspace or cancel the lease etc.
It's not a simple issue, and I contend it's not a job for the individual River
services nor for the mechanics of remote calls. It's an application design
issue. Distributed systems need something on the outside that manages load and
handles requests at a higher level as they come into the system so that the
mechanics of all the services are unimpeded in performing the tasks they are
designed/need to perform to work correctly.
Gregg Wonderly
