mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Trustin Lee" <trus...@gmail.com>
Subject Re: Huge SessionBuffer event queue empties too slowly
Date Mon, 15 Jan 2007 03:38:18 GMT
On 1/12/07, Paul Mallach <pm@ariva.de> wrote:
> Hi!
> > 1) Branch 1.1 (and I guess that trunk too) are using a
> > ConcurrentLinkedQueue instead of an Array. So performance with big
> > queues should be better.
> You're right. I switched to 1.1 yesterday and thanks to
> ConcurrentLinkedQueue
> the 2 million elements were processed in a matter of minutes.
> I have also employed another patch: Before this, the million messages were
> sent while in the IoHandler.messageReceived() method, that received the
> request. It basically looked like this:
>         public void messageReceived(IoSession session, CmdReplicate
> message) {
>                 for ( int i=0; i<1000000; i++ ) {
>                         session,write(new Quote());
>                 }
>         }
> Now it returns immediately after spawning a new thread, that sends the
> million
> messages. This way the heap doesn't grow at all, because -- as you pointed
> out in your mail -- all internal mina messages can be processed at once
> and
> the queue doesn't grow at all.

It's interesting.  So incoming messageSent() events caused by session.write(new
Quote()) are not being processed until messageReceived(IoSession,
CmdReplicate) ends.  Writing from a separate thread is a good idea here,

> 2.2) change your thread model (e.g. add another ExecutorFilter after
> > your ExecutorFilter) so that you have a pool of threads processing the
> > events queue.
> I'm not sure that this could have worked in this case. Doesn't MINA
> guarantee,
> that all messages get processsed in order? Then no new message would have
> been scheduled to be processed, before the first command (that start the
> replication) had been processed. Or would adding another ExecutorFilter
> mean
> that mutliple messages are processed at the same time?

ExecutorFilter is designed to maintain the order of messages.  To process
multiple message at the same time, you have to program your own filter.
Probably we could modify an ExecutorFilter that optionally disables event
ordering.  Here's the JIRA issue:


Of course, if you are interested in providing this feature, a patch is
always welcome.  :)

what we call human nature is actually human habit
PGP key fingerprints:
* E167 E6AF E73A CBCE EE41  4A29 544D DE48 FE95 4E7E
* B693 628E 6047 4F8F CFA4  455E 1C62 A7DC 0255 ECA6

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message