river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patricia Shanahan <p...@acm.org>
Subject Re: TaskManager
Date Tue, 05 Jul 2011 13:03:52 GMT
The different thread pool implementations allow different constructor 
parameters. Perhaps a factory pattern?

I think it would make run time selection of an alternative 
implementation easier, but make it harder for a class to specify 
parameters. On the other hand, I'm not sure how informed and meaningful 
the per-using-class parameters are.

Also, does it make sense to have separate pools, if we remove runAfter 
as a thread pool feature? Maybe we should have one pool for all River 
code running under a single JVM? That would improve thread sharing, and 
simplify the parameters.

(I would oppose combining pools with runAfter, because of O(n^2) behavior).


On 7/5/2011 1:12 AM, Tom Hobbs wrote:
> Would it be possible t extract the whole thing into an interface?  Have the
> river default implementation something similar to what we have now (at least
> in behaviour if not implementation) but allow users to swap in their own
> task execution implementations that may or may not throttle in some way.
> Just a thought.
> Grammar and spelling have been sacrificed on the altar of messaging via
> mobile device.
> On 1 Jul 2011 21:29, "Patricia Shanahan"<pats@acm.org>  wrote:
>> On 7/1/2011 1:14 PM, Gregg Wonderly wrote:
>> ...
>>> If the system throughput is not meeting my needs, I'll apply admission
>>> controls, or "add hardware" to manage the issue. Anything else done by
>>> river only serves as a "limit" that can be very frustrating to debug and
>>> deal with.
>> I would like to make any River controls e.g. on the number of threads
>> for some purpose configurable. A site that does not want any River
>> controls would configure the upper limits on threads to be
>> Integer.MAX_VALUE.
>> If we get rid of the runAfter issue, we could possibly reduce the number
>> of separate thread pools, making configuration simpler. runAfter, as
>> currently implemented, introduces some O(n*n) behavior, where n is the
>> number of incomplete tasks.
>> Patricia

View raw message