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).
Patricia
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"<p...@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
