river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: TaskManager progress
Date Sun, 25 Jul 2010 20:47:37 GMT
Patricia Shanahan wrote:
> 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
We could utilise Prioritised thread pool's if we had a security check 
when requesting the TaskManager (or RunnableManager etc),   all tasks 
could be sent to the same pool and queue, however the less priveleged 
(as determined by the static method when obtaining the thread pool) 
would always end up on the back of the queue under load.

There are other protections in place too such as Method Constraints that 
proxy's must satisfy.  The biggest potential for denial of service at 
this stage is downloading of jar archives for proxy's, however if the 
client provisions these jar files instead and the jar archive size is 
advertised in an Entry, the client might only select the services it can 
handle and then limit the download size to the Entry's advertised size.


View raw message