Hi, 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.
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. 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. If other people are interested in trying our filter I'd be very interested in seeing the performance they get. 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). I would recommend that idle events and maybe others are processed directly rather than being put on the queue of session events. RG
