Hi Robert, On 10/17/06, Robert Greig <[EMAIL PROTECTED]> wrote:
Some of you may know that the Qpid project, which I am a committer on, uses MINA (and has done since its inception even before it moved to Apache). Qpid is a message broker that implements the nascent AMQP protocol.
Congratulations for the incubation, and I wish you good luck. I hope we collaborate closely on MINA. We had developed our own thread pool that made use of
java.util.concurrent features. I have now compared this with the new executor filter that was introduced after version 0.9.5. Our thread pool is available here: https://svn.apache.org/repos/asf/incubator/qpid/trunk/qpid/java/common/src/org/apache/qpid/pool/ In my tests the throughput in our application is more than doubled when using our thread pool as compared with the default MINA one.
That's exciting. Can we adopt the code after we move to Java 5? We will move to Java 5 soon. I am not entirely sure why this is the case but here are some differences:
1) we require less synchronisation because we use some of the java.util.concurrent features for the session event list (e.g. ConcurrentLinkedQueue as opposed to ArrayList), and a ConcurrentMap for the session->event list mapping. 2) We allow the filter to choose which events to add to the queue. So we have two pools configured - one at the front of the filter chain that does reads, and one at the end that does writes. This means that reads and writes can be processed concurrently on a box with enough CPUs.
Makes sense. One other issue with the current filter. We use idle events to
implement heartbeats. This means that we cannot allow the idle events to be queued up like e.g. read events. If there is a big queue of pending events, the idle event might not be processed for a while which results in a delay to the heartbeat being sent. (e.g. consider the case where you read a lot but are not writing - you need to write a heartbeat every so often to let the other end know you are still there).
Why don't you create a demultiplexing IoFilter which decorates a thread pool filter? The filter could make the messages with higher priority bypass the thread pool. Otherwise, you could have two thread pool filters in it and choose which pool to use, although it doesn't guarentee the thread safety at all. Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP key fingerprints: * E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E * B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6
