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.
> 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?
Thanks!
bye, Paul.
--
ARIVA.DE AG, Paul Mallach, Produktentwicklung
Walkerdamm 17, 24103 Kiel
Tel.: +(49) 0431/97108-23, Fax: +(49) 0431/97108-29
E-Mail: [EMAIL PROTECTED], Web: www.ariva.de
