Notes:
ServiceDiscoveryManager
NotifyEventTask
If the task list contains any RegisterListenerTasks
or LookupTasks associated with this task's lookup service
(ProxyReg), and if those tasks were queued prior to this
task (have lower sequence numbers), then run those tasks
before thi
Two emails are worth reflecting on, as is River-344, this relates to
replacing TaskManager with ExecutorService.
http://mail-archives.apache.org/mod_mbox/river-dev/201107.mbox/%3cbb4ad312-53c1-4ce6-9bff-01e5cc344...@sorcersoft.org%3e
http://mail-archives.apache.org/mod_mbox/river-dev/201105
> > >
> > > This linking of application behavior into utility APIs is just not
> > > good, testable design. It requires that behaviors on the outside
> > > of the pool, flow through to other uses of the API in
> > > non-programatic design ways.
>
that behaviors on the outside of the pool,
>> flow through to other uses of the API in non-programatic design ways.
>>
>> Gregg Wonderly
>>
>> On Jan 4, 2014, at 7:46 PM, Peter wrote:
>>
>>> For a moment, lets consider how we might fix TaskM
havior into utility APIs is just not
> > good, testable design. It requires that behaviors on the outside of
> > the pool, flow through to other uses of the API in non-programatic
> > design ways.
> >
> > Gregg Wonderly
> >
> > On Jan 4, 2014, at 7:46
the outside of the pool,
> flow through to other uses of the API in non-programatic design ways.
>
> Gregg Wonderly
>
> On Jan 4, 2014, at 7:46 PM, Peter wrote:
>
> > For a moment, lets consider how we might fix TaskManager, while
> > retaining the existing
:
> For a moment, lets consider how we might fix TaskManager, while retaining the
> existing Task.runAfter method and how the fix would impact TaskManager's
> users.
>
> TaskManager, like most thread pools has a queue.
>
> Before a task is removed from the queue for ex
For a moment, lets consider how we might fix TaskManager, while retaining the
existing Task.runAfter method and how the fix would impact TaskManager's users.
TaskManager, like most thread pools has a queue.
Before a task is removed from the queue for execution, it is asked if it s
The problem is with TaskManager's public api method Task.runAfter. This is
well documented in River-344.
The fix requires changing every class that uses it
As a thread pool TaskManager is correct provided that no ordering dependencies
exist between tasks.
TaskManager doesn't compa
I’d like you to make a reasonable case for why TaskManager needs to be
replaced, requiring changes to many other classes that depend on TaskManager,
rather than stating what the problem is with TaskManager and seeking to fix it,
which would only affect TaskManager and not require modifying and
Would you like me to add this class, so that existing configurations
utilising a TaskManager can also be used? This might be useful for
retaining backward compatibility with existing configurations?
Regards,
Peter.
/*
* Licensed to the Apache Software Foundation (ASF) under one
* or more
Hi Patricia,
On 4/8/13 4:32 PM, Patricia Shanahan wrote:
Thanks for the background. The general performance of TaskManager, and
especially the overhead for runAfter, seemed to me to depend strongly on
the queue length. For example, a non-trivial runAfter method scans the
list of tasks older
rogrammer, opposed to putting the burden on them to arrange for it
themselves.". I concluded runAfter is *not evil* by itself when properly
used, although it gives some overhead and it has to perform its work
while a lock has been held.
...
Thanks for the background. The general performance of
els messy to me.
>
Agreed, we should probably consider each case individually, I noticed there's a
configuration property that allows a TaskManager instance to be injected on a
number of occasions too, which suggests there might be some sharing.
Peter.
> On 4/3/2013 2:04 PM, Dan Creswe
with the idea of understanding the use cases before designing the
solution, and with using standard API classes as much as possible. The
table I sent you was intended as a first step towards that.
I'm not convinced that the right solution is a single TaskManager
successor. Different TaskManag
e with the idea of understanding the use cases before designing the
> solution, and with using standard API classes as much as possible. The
> table I sent you was intended as a first step towards that.
>
> I'm not convinced that the right solution is a single TaskManager
> successo
I agree with the idea of understanding the use cases before designing
the solution, and with using standard API classes as much as possible.
The table I sent you was intended as a first step towards that.
I'm not convinced that the right solution is a single TaskManager
successor. Diff
Gut feeling suggests the solution will be executor based, so you're asking good
questions, I think we need to understand the use cases better and probably
redesign dependant code too.
One example of retry, the task will continue attemtping to retry for an entire
day.
We might need some kind of
, because whenever a task
finishes the TaskManager has to ask each waiting task whether it still
needs to wait for any older task. I wanted to change it so that
TaskManager would know which task was being waited for. It could then
associate with one task a list of tasks that need to be reconsidered
when
I am not clear on the semantics for runAfter, but maybe this can be
achieved by wrapping a Runnable within another Runnable such that the 2nd
runnable is automatically scheduled after the first has succeeded?
Likewise, it is possible to wrap a Runnable in order to automatically
retry if it throws a
t
attempt at taskA fails, and it puts itself back on the TaskManager
queue, using the normal add call. Now taskA is after taskB.
Patricia
On 4/2/2013 12:38 AM, Peter Firmstone wrote:
The formatting didn't work out, I'll create a Jira issue to discuss.
Patricia's done a great j
. Suppose taskA is a RetryTask, taskB is supposed to runAfter
taskA, and originally appears on the queue after taskA. The first
attempt at taskA fails, and it puts itself back on the TaskManager
queue, using the normal add call. Now taskA is after taskB.
Patricia
On 4/2/2013 12:38 AM, Peter F
On 7/7/2011 2:26 PM, Mike Sobolewski 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
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:
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 us
c 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
On Wed, 29 Jun 2011 10:06:02 -0400
"Christopher Dolan" wrote:
> P.S. can someone add a link to the Incubator mail archives to the web
> page? They are quite hard to find...
> http://mail-archives.apache.org/mod_mbox/incubator-river-dev/
> http://mail-archives.apache.org/mod_mbox/incubator-riv
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
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.
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 a
nable
chance at throughput.
Equally a vast majority of tasks can only have a reasonable chance of
throughput in the presence of sufficient resource. The point of
TaskManager is to control resource consumption (including processor
utilisation) which naturally asserts a limit on throughput.
...
er-load so needs admission control etc to make that
>> stick).
>>
>>> I don't like this thought at all in a distributed system. A vast
>>> majority
>>> of tasks really need to be invoked immediately to maintain a reasonable
>>> chance at through
jority of tasks can only have a reasonable chance of
throughput in the presence of sufficient resource. The point of
TaskManager is to control resource consumption (including processor
utilisation) which naturally asserts a limit on throughput.
...
Some resource limitation is definitely necessary
he maximum number of threads, but can equally well
>> be set to have up to Integer.MAX_VALUE threads, effectively unlimited.
>
> Yes, this is the case. There are some other subtle behaviors which we just
> need to study to make sure that the "documented behavior" is what we ne
UE threads, effectively unlimited.
Yes, this is the case. There are some other subtle behaviors which we just need
to study to make sure that the "documented behavior" is what we need.
There are two forms of TaskManager behavior that I do not see an easy
way to reproduce using a simpl
o forms of TaskManager behavior that I do not see an easy
way to reproduce using a simple ThreadPoolExecutor, runAfter and loadLevel.
runAfter my be better handled by the class issuing the tasks.
loadLevel permits specification of a ratio between threads and tasks, so
that threads are only created
g/mod_mbox/incubator-river-user/
http://mail-archives.apache.org/mod_mbox/incubator-river-commits/
-Original Message-
From: Peter Firmstone [mailto:j...@zeus.net.au]
Sent: Sunday, June 26, 2011 5:18 PM
To: dev@river.apache.org
Subject: Re: TaskManager
> I think the way to look at this
; >
> > > We are now committed to 1.5, so if we did not have runAfter we could
> > > replace TaskManager with java.util.concurrent.ThreadPoolExecutor.
> >
> > That's probably where we should be headed, since it reduces our
> > maintenance burden.
>
>
, so if we did not have runAfter we could
replace TaskManager with java.util.concurrent.ThreadPoolExecutor.
That's probably where we should be headed, since it reduces our
maintenance burden.
It's also a direction that suggests an easy step-wise route from here to
there. I propos
replace TaskManager with java.util.concurrent.ThreadPoolExecutor.
That's probably where we should be headed, since it reduces our
maintenance burden.
Peter.
On 6/26/2011 1:58 PM, Peter Firmstone wrote:
Patricia Shanahan wrote:
On 6/26/2011 1: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 i
Patricia Shanahan wrote:
On 6/26/2011 1: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 y
On 6/26/2011 1: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
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 a
44 matches
Mail list logo
