Hello,
Trustin Lee wrote:
Hi folks,
I've just added a very interesting feature, which overlaps with
org.apache.mina.filter.traffic. The difference if that it attaches to
the new ThreadPoolExecutors - OrderedThreadPoolExecutor and
UnorderedThreadPoolExecutor. You can specify an IoEventQueueHandler
in the constructor. IoEventQueueHandler provides some hook methods
for vetoing the event from getting into the queue and monitoring flow
of events. IoEventQueueThrottle is the first implementation of
IoEventQueueHandler. It is much simpler than
org.apache.mina.filter.traffic classes because it interacts
ThreadPoolExecutors directly. Please take a look into the source
code:
http://svn.apache.org/viewvc/mina/trunk/core/src/main/java/org/apache/mina/filter/executor/IoEventQueueThrottle.java?view=markup
As you can see from the source code, it doesn't use IoSession traffic
mask operation; it just blocks on Executor.execute() and unblocks on
notification. Trade-off of this simplicity is that there's no various
scope type in threshold value, in contrast to ReadThrottleFilter. It
will be more efficient and won't burden call stack depth at all
instead, while fulfilling most people's demand.
I'm testing the scenario where a I have a server (Mina based), n (n>=1) message
producers and one message consumer in which I measure the number of
messages/second received.
Results for one producer:
With ReadThrottleFilter: ~12K messages/sec
With OrderedThreadPoolExecutor/IoEventQueueThrottle: ~12.5K messages/sec
With two producers:
With ReadThrottleFilter: ~12K messages/sec
With OrderedThreadPoolExecutor/IoEventQueueThrottle: 6K messages/sec
What can explain that sharp drop in throughput when using this new
IoEventQueueThrottle?
--
Luis Neves
