[Jcyclone-devs] Addition of ConcurrentThreadPool to JCyclone

[Toli K. <to...@ma...>]

Jean (and others),

We've taken a look at the changes you proposed for making the
ThreadPool more efficient, and it seems that it may be easier to just
re-implement it using the native Java concurrency stuff.

If having JCyclone depend on Java 1.5 is acceptable, then it's a lot
easier to implement the concrrent thread pool using the built-in
concurrentcy functionality.

We've put together a set of changes that creates a new
TPSConcurrentScheduler.java class that uses the built-in concurrency,
along with a set of unit tests that runs using both the old
TPSScheduler and the new concurrent scheduler.

The changeset consists of 3 files:
patch.out - apply using the usual patch -p0 < patch.out command from
jcyclone/core directory, this modifies the existing files.
patch-MapConfig.out - the last time i checked in code i had the
MapConfig.java file be in DOS mode (with \r\r line endings). I
couldn't figure out a clean way to have patch work with 2 kinds of
line endings so this patch file is separate)
patch-newFiles.zip - to be expanded in jcyclone/core directory. this
contains the new src and test files.

Here's the general list of changes:
MapConfig.java
 - i actually had a bug in this class that i found with a unit test.
it's been fixed.
test/org/jcyclone/core/cfg/FileConfigTest.java
test/org/jcyclone/core/cfg/JCycloneConfigTest.java
test/org/jcyclone/core/cfg/MapConfigTest.java
  - added unit tests for File/MapConfig
TPSSchedulerConcurrent
 - implementation of a concurrent thread pool scheduler using the java
cocurrency code
build-junit.xml and build-junit-shared.xml
 - refactored the junit build code to live in a shared file. this is
more of a personal preference/nicety - we can't use the regular
build.xml file b/c it's referring to the share.xml file that doesn't
exist in the same directory, so we factored out the junit code to be
coming in from a shared file we can include in a different
build-xxx.xml file

src/org/jcyclone/core/boot/JCyclone.java
In order to make it easier to write unit tests, i modified JCyclone to
allow for starting/stopping it multiple times. It is still essentially
a signleton, but i've added code to allow for it to be reset and
restarted again.
src/org/jcyclone/core/cfg/JCycloneConfig.java
 - added the constant for the new scheduler
src/org/jcyclone/core/internal/TPSScheduler.java
 - found a bug - the code actually doesn't remove anything during
deregisterAll(). Didn't actually fix the bug - it breaks the
subsequent implementation of deregister().
Basically, currently JCyclone calls deregisterAll() and the
subsequently deregister() on each stage. So each stage was being
deregistered twice. We didn't fix the workflow, but modified our
TPSSchedulerConcurrent to handle double calls to deregister correctly.

src/org/jcyclone/core/stage/JCycloneMgr.java
code to recognize the new scheduler
test/org/jcyclone/core/internal/Consumer.java
test/org/jcyclone/core/internal/ConsumerSingleThreaded.java
test/org/jcyclone/core/internal/Producer.java
test/org/jcyclone/core/internal/ProducerSingleThreaded.java
test/org/jcyclone/core/internal/SchedulerTestBase.java
test/org/jcyclone/core/internal/TPSConcurrentScheduler_MixedThreadingTest.java
test/org/jcyclone/core/internal/TPSConcurrent_SingleThreadedTest.java
test/org/jcyclone/core/internal/TPSSchedulerConcurrentTest.java
test/org/jcyclone/core/internal/TPSSchedulerTest.java
test/org/jcyclone/core/internal/TPSScheduler_SIngleThreadedTest.java
test/org/jcyclone/core/internal/ThreadSampleEvent.java
  - code for creating the simple producer/consumer framework for unit
testing the TPS schedulers.
Producers send events, and consumers are stages that recieve them, and
then add them back to the test. we then verify that all events go
through, that they are in right order (if appropriate), etc.
there are multiple setup combinations: one-one (producer-consumer),
many-one, many-many, etc; both with original TPSScheduler and
TPSSchedulerConcurrent.
Tests are written to be somewhat random - stages may wait a random
amount to send an event, and will send a random # of events as well. I
wrote it that way to introduce more randomness in order to force
concurrency/scheduling issues to surface faster.

in addition to using the java concurrency code (1.4) the unit tests
also use generics from 1.5.

the unit tests now take about 8-9 minutes to complete (run them with
ant -f build-junit clean junit).

let me know what you think.

--
Toli Kuznets
http://www.marketcetera.com: Open-Source Trading Platform
download.run.trade.