JXSE 2.5 : What's Cool #6 -- PeerGroup Executor and ScheduledExcutor

http://weblogs.java.net/blog/bondolo/archive/2007/10/jxse_25_whats_c_5.html

————————————————————————————————————————————————————————

 

JXSE 2.5 : What's Cool #6 -- PeerGroup Executor and ScheduledExcutor

Posted by bondolo on October 9, 2007 at 1:32 PM EDT

JXSE (JXTA for Java SE/EE 5.0) 2.5 contains quite a number of exciting changes for JXTA application developers. This little series will look at a few of the important changes in the upcoming release.

JXSE 2.4 was the first version to require Java Standard Edition 5.0. For that release we used only a small amount of JSE 5 specific functionality. The requirement of JSE 5.0 was primarily about advancing the support matrix to include the then newly released JSE 6 and providing the opportunity to take advantage of new features in future releases. In JXSE 2.4.1 we started to make much greater use of JSE 5.0 specific APIs, and most significantly the new java.util.concurrent utilities. In JXSE 2.5 we have continued to make much greater use throughout the JXSE source.

The concurrency utilities provide several flavours of task executors. The Executor and ScheduledExecutor classes provide a convenient way to execute tasks without the overhead of the normal Thread lifecycle. For JXSE the use of Executor is a very good fit. There are a very large number of short lived operations or tasks that JXSE performs to maintain the JXTA network and to handle application I/O. JXSE currently makes fairly heavy use of Timer for periodic maintenance tasks. We expect that in future JXSE releases we will replace all of the Timer usage with ScheudledExecutor.

One difficulty we have found with Executor is that the default policy is not well suited to I/O frameworks. The standard policy uses a fixed base number of threads and a fixed size queue. If the queue fills then additional threads are started to a fixed maximum. The policy that would work best for JXSE and other I/O driven systems is a fixed base number of threads and a fixed size queue. Additional threads would be started for additional tasks to a fixed maximum. After that tasks would be queued to a fixed maximum at which point the task submitters would block until their tasks could be enqueued or executed. The effect of the default policy is that when the base of Threads are occupied new tasks will be started with much higher latency unless the system is entirely saturated with tasks.

The Executor interface does allow some policy to be controlled, but we haven't really figured out how to effectively override the standard policy. Suggestions and or contributions would, of course, be very welcome!