One of the problems I've had when promoting MINA is that most Java developers don't understand the scalability implications of the thread-per-connection architecture. If I jump right in with how cool MINA is with its separation of concerns, futures, filters, event mechanism, simplifies packet fragmentation problems, etc., the audience either gets lost or replies with something like, "Using InputStreamsis just as flexible as filters but doesn't come with all the difficulties of having to build a state machine. MINA just makes things complicated!"
However, if I start out showing how quickly I get an OOM exception when using a thread-per-connection architecture and then show how I can handle thousands of connections in MINA without consuming loads of memory, the audience is able to better understand the main problem that MINA solves. Showing how painful it is to use NIO directly is fairly simple at this point. The important part is making sure the audience understands the need for the functionality that NIO has to offer. Once the audience understands the problems MINA solves, I've found they're usually much more receptive to the coolness that MINA has to offer. Just my $0.02. -Mike 이희승 (Trustin Lee) wrote: > Hi, > > I was invited as a speaker of JavaOne 2008 and will speak about Apache > MINA there. Please feel free to contact me to give me some idea about > what you want to hear about MINA if you have any plan to attend this > year's JavaOne. > > Cheers, > Trustin