river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregg Wonderly <gr...@wonderly.org>
Subject Re: com.sun.jini.thread lock contention
Date Thu, 10 Jun 2010 05:51:01 GMT
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 

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

View raw message