On 6/24/2010 5:24 AM, Peter Firmstone wrote:
Patricia Shanahan wrote:
Peter Firmstone <[email protected]> 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
