On 1/12/07, Paul Mallach <[EMAIL PROTECTED]> 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,
too.
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:
http://issues.apache.org/jira/browse/DIRMINA-334
Of course, if you are interested in providing this feature, a patch is
always welcome. :)
HTH,
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
