> 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. > > 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. > > 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:-) Ilya
