river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: com.sun.jini.thread lock contention
Date Sat, 05 Jun 2010 03:05:15 GMT
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.
>   
Ditto.

    /**
     * Create a task manager with maxThreads = 10, timeout = 15 seconds,
     * and loadFactor = 3.0.
     */
    public TaskManager() {
    this(10, 1000 * 15, 3.0f);
    }

public TaskManager(int maxThreads, long timeout, float loadFactor)

Cheers,

Peter.

Mime
View raw message