river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patricia Shanahan <p...@acm.org>
Subject Re: A new implementation of TaskManager
Date Mon, 05 Jul 2010 21:02:56 GMT
On 6/24/2010 5:24 AM, Peter Firmstone wrote:
> Patricia Shanahan wrote:
>> Peter Firmstone <j...@zeus.net.au> wrote:
>>> A new implementation of TaskManager could take advantage of:
>>>
>>> java.util.concurrent.PriorityBlockingQueue
...
>>> If we are to refactor the classes in com.sun.jini.thread, I think we'd
>>> need to refactor everything that relies on them too and this will take
>>> some work.
>>>
>>> If someone is willing to donate time, I'm certainly for such a
>>> refactoring.
>>
>> I'm an experienced Java programmer looking for a useful and interesting
>> open source project, and River was one of the suggestions I've received.
>
> You've definitely come to the right place, we have some interesting
> fundamental issues, ripe for picking.
>
>> Other than having used Subversion, I have no knowledge of Apache build,
>> test, and documentation conventions. I need a task where delays due to
>> my Apache learning curve are not going to delay any other work.
>>
>> Do you think this refactoring would be a suitable task?
...
> Yes certainly, don't be afraid to dive in, welcome to Apache River.
...

Now that I've made some progress on building and testing, I'm ready to 
return to the substantive issues of the TaskManager refactoring project.

I've read the "com.sun.jini.thread lock contention" thread. I think at 
this point the best strategy is to keep TaskManager, update its 
interfaces to improve performance, and use API classes available in JDK 
1.5 as applicable in its implementation.

I see two objections to directly exposing ThreadPoolExecutor or similar 
to the TaskManager callers.

1. There are new features in 1.6 that may be useful, but not until River 
moves to 1.6. I would prefer to avoid having to change all the callers 
to make use of future features. For example RunnableFuture is a 1.6 
interface.

Even within a ThreadPoolExecutor based implementation, I think the 
pending tasks can be handled most simply by not handing them over to the 
executor until they are ready to execute.

2. River may need some global data collection and operations to support 
resistance to denial of service attacks. Having a central task manager 
class may make that easier, if it is ever needed.

I have two immediate questions:

1. Are the current tests considered adequate? If nobody has an opinion, 
I'll review them before starting on refactoring.

2. What areas of TaskManager performance most need improvement? What are 
my objectives? The current implementation seems to me to be likely to 
work quite fast for lightly loaded instances with few tasks, and even 
fewer pending tasks, but unlikely to scale well. Is that correct? Are 
there any known test cases that demonstrate performance problems?

Patricia

Mime
View raw message