river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Hobbs <tvho...@googlemail.com>
Subject Re: TaskManager
Date Tue, 05 Jul 2011 08:12:45 GMT
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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message