Ilya Sterin wrote:
So it makes sense that, using an OrderedThreadPoolExecutor, the messages are
processed one after the other on a single thread. The
OrderedThreadPoolExecutor contract is clear : it keeps the event being
processed in the order they arrive across a session.
Well, it didn't make sense using 1.1.6, since there was no concept (at
least from what I can tell) of ordered or unordered executors. You
just simply pushed an ExecutorService into the stack. The
documentation didn't state that request are going to be ordered. I
didn't see that explanation until I saw the doc that explained the
difference between 1.* and 2.0. I might of missed some other doc
though.
Nope, you're right. I was considering 2.0, my mistake.
Depending on the machine, I think that MINA can afford the load. The tests
we have done on ADS (in the case we are having one single client, thus one
single session, and an orderedThreadPoolExecutor) shows that, on my Centrino
duo laptop, we can reach around a thousand LDAP request per second.
That depends on your network and latency. MINA itself can process
huge amounts of loads, we never had an issue with that. We had an
issue with latency in our IoHandler implementation which pushed this
data over a rather latent connection for persistence.
Even on MINA 2.0, there is a problem with such latencies (either because
of a fast writer - but you can throttle the incomong requests) or
because of a slow reader (and we currently have no solution). Of course,
'slow' is relative, and depends on your internal processing (slow
decoding and/or processing).
Do you mean you _were_ able to process only 6 req/s with mina 1.1.6 or that
your application was receinving this load ? In other words, are these the
limits you have reached ? I would be very surprise to hear that MINA 1.1.6
was not able to process more than 6 req/s ...
Yes, 6 requests due to IoHandler overhead. The protocol codec thread
is able to handle thousands of requests per second, that's never been
an issue. Our setup is a bit constrained. We receive data over a LAN
and then write it to the db over a rather latent WAN connection. So
due to network io latency, our db inserts were down to 6 per second
within a single thread and the only way to scale that was to increase
the # of IoHandler threads, which we couldn't do with 1.1.* version.
We could of course handle our own thread management and spin off
threads and then return from IoHandler to allow it to keep processing,
but I was always under the impression taht mina's thread model took
care of that, at least that was my understanding from the docs. There
was no mention, at least 6 months ago when we first did this, of
ordered executions in the thread model, which really makes the thread
model useless for IoHandlers, at least from a standpoint of having a
fixed thread executor with more than one thread, there was no point.
Now, with 2.0, we're able to almost keep up with the Io Processor
thread and our IoHandlers are executed in an unordered thread model.
That's great, we're happy now:-)
Ok, I understand now. And, yes, MINA 2.0 brings a much better handling
on such a situation.
Thanks for the explanations !
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
