On 7/24/2010 6:57 PM, Peter Firmstone wrote:
Hi Patricia,
Don't even know if the following compiles, the intent was to make it
possible for the a RunnableDep to be depended on Remotely, allowing all
sorts of Dependant Runnables to sort out their differences. I also
envisioned a singleton RunnableManager for a JVM instance to enable
tuning the number of threads.
I think we should keep separate thread pools, rather than going to a
single centralized thread pool. I am concerned about both deliberate
denial of service attacks, and bugs that mimic them by causing message
floods.
In the current design, for example, decoding messages gets to use a
limited set of threads, and other threads are reserved for activities
that complete work. If we used a single thread pool, a message flood
could overload that pool with message decoding tasks, delaying anything
that completes work, risking out-of-memory conditions.
I am not at all sure that the current choices of mapping of tasks to
thread pools is ideal for robustness, but I don't know enough yet to
contribute to redesign in that area.
I do agree that we need some way of tuning the number of threads. A
large server can happily live with many thousands of threads. A small
laptop might not be so happy. Maybe we should be looking at having two
levels of control:
1. Proportion of threads to allocate to some use, fixed in the source code.
2. Total number of threads to allocate across all uses, determined at
run time.
Patricia
