river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Sobolewski <so...@sorcersoft.org>
Subject Re: TaskManager
Date Thu, 07 Jul 2011 21:26:48 GMT
The object that created an instance of TaskManger knows what is in its manger queue.
However, tasks are usually coming from outside. They can be recorded initially before  
appending them to the  queue, but later the order can be still updated.
For me a simple reordering based on a task priority would work well.

Below additional related comments from another email thread:
On 7/7/2011 6:11 AM, Mike Sobolewski wrote:
> On Jul 6, 2011, at 11:19 PM, Patricia Shanahan wrote:
>> I'm curious about why the load factor option is desirable. Suppose
>> you have 30 tasks waiting, and you have could afford 30 threads for
>> the function, then why not allow 30 threads? The load factor has
>> the effect of limiting the throughput even when you would create
>> more threads if there were more tasks.
> On 7/7/2011 9:11 AM, Mike Sobolewski wrote:
> The issue is not in having enough threads to process all existing
> tasks but in a reasonably "smooth" number of threads over long time
> so temporary peaks of many tasks can be handled by smaller number of
> threads with no need to create additional many threads for a short
> moment and release them after that temporary peak over and over.

On Jul 7, 2011, at 4:39 PM, Patricia Shanahan wrote:

> Generally, tasks in the same TaskManager instance were all created by
> the same object, and their class is, or could be, an inner class in that
> object, and therefore they *could* talk to each through methods in that
> object.
> I'm not sure the current runAfter mechanism is right for all the uses to
> which it is being put. My inclination is a gradualist approach, in which
> as we modify TaskManager uses to java.util.concurrent we look at the
> runAfter motivations and write code to implement them. If multiple uses
> have similar needs, we can abstract out the solution and share it.
> One candidate I've been thinking about is a
> Map<T,List<RunnableWithKey<T>>> where RunnableWithKey<T> objects
have a
> method "T getKey()" and instances with the same key run in order of arrival.
> Patricia
> On 7/7/2011 7:00 AM, Gregg Wonderly wrote:
>> Can we institute a "call back" mechanism to handle this issue in a way
>> that allows the "dependent" code to be run from the "after" task so that
>> the serialization of the work is explicitly specified?
>> Having a failed announcement come back might be appropriate too. It
>> seems like runAfter() doesn't allow for the tasks to talk to each other
>> about whether progress was made to allow the next step to proceed with
>> any chance of success.
>> Something like the following might be appropriate.
>> public interface ExecuteAfter extends Runnable {
>> public void failed( Throwable ex, Object dependent );
>> }
>> Gregg
>> On 6/26/2011 3:23 PM, Peter Firmstone wrote:
>>> There's an interesting thread of discussion in the Porter mail archive
>>> that Mark
>>> has uploaded for us (see River-311), relating to the TaskManager.
>>> Here's a very interesting comment from Bob Scheifler:
>>> Over the years we've been slowly eliminating use of Task.runAfter, and
>>> in any overhaul I'd prefer to finish that job rather than perpetuate it.
>>> I have in a past life been a fan of deadline scheduling.
>>> Any thoughts?
>>> Cheers,
>>> Peter.

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