Apache MINA has always been the preferred choice by many programmers, but I found almost no documentation, lack of simplicity and questionable high performance – what I mean is that we needed to send 2000 messages per second in our app, well, very few people usually need that much of a traffic, but shooting with MINA 1000 messages at one time brings not more than 900 at the other end.

how about you check with current technology instead of living in old dead mantras.

NIO is currently not faster then blocking IO.
just test it with a linux 2.6 kernel with its NPTL.

you will see that for loads at thousands of connections, blocking IO wins with roughly 25% in all kinds of tests.

if you run windows etc, well its your own fault if thinking its a good server.

http://osflash.org/red5

14. In the long run every program becomes rococo – then rubble.

30. In programming, everything we do is a special case of something more general — and often we know it too quickly.

52. Systems have sub-systems and sub-systems have sub- systems and so on ad infinitum – which is why we’re always starting over.

And that is my point of view:

31. Simplicity does not precede complexity, but follows it.

For me, main selling point of those frameworks is flexibility, because there are interfaces for everything.However, I don’t need this flexibility.

I never wanted to say that those frameworks are slow. Their authors will claim that “you are just using them in wrong way”. But that is exactly my point: instead of doing something in straight way, you need spend time learning those frameworks.

It is always possible to prove that those frameworks are not flexible enough for your case. But then authors will introduce additional layer of interfaces to satisfy you.

Yes, my evaluation is not deep, but this is exactly the point: they are useless in advance, and even require learning. I don’t want to learn pipeline models of those frameworks, because I strongly suspect that it is a several layers of abstractions made over something very simple. I don’t want to follow stupid patterns, becase someone considers them good, and because of abstract virtues of “separation of concerns”. I belive that all those frameworks are very similar, and no one has clear benefits compared to others. It is not worth my time to see how they are different between each other, because I’m certain that finally I’ll discover that they are clones of each others, just classes have different names.

Yes, this article doesn’t look like serious investigation, but it didn’t mean to. There are no need to look deep in code to understand that it is worthless. I know that just because socket servers simple enough to be written in plain form.

But, if anyone wants other arguments, I have one more. Look at MINA, especially package org.apache.mina.transport.socket. There is a large amont of methods consisting of 1-3 lines of code. Just wrappers, sometimes with exception catching. This is called “code smell”, and naturally solved by refactoring “inline”.

Can anybody name a really usefull and widespread server product which uses those libraries ? Can anybody explain why C programmers live happily without such frameworks ? Can anybody explain if those libraries are so good, why there are so many of them ?

Ultimately this article boils down to the following summary: “Here are four NIO frameworks. Don’t use them. They are tricky.” How? Why? Concrete examples and comparisons please.

I am not starting a fight between custom-brewed NIO vs frameworks or similar… each task requires the proper tool. I’ve been using MINA and xSocket when I was in a hurry and didn’t mind about the ultimate performance. They worked okay with a few problems here and there, but acceptable.

For very high performance a custom solution worked much much better than Mina, so I agree with the “too generic framework” critique.

If you’re curious about it I’ve published (last summer) a few comparison tests between a Mina-based socket server and our custom-NIO engine -> http://www.smartfoxserver.com/forums/viewtopic.php?t=1850&highlight=mina

Hello man! You start your comment by questioning my if my experience is big enough to have right to judge about this code. Well, I suppose it is big enough, because I don’t think that “NIO is tricky”, as you say. You accuse me of being “authoritan”, but I never use words like “must”/”mustn’t”, I always say that it is just my opinion. And hey, this is my blog, I can express my opinion here! I understand that my article had probably hurt your feelings, that’s why you are attacking me personally, not my arguments. Please, don’t be rude next time! Oh dear, this blog was so quiet, but I’m afraid it will be a place of flamewar.

OK, let’s go to the matter.

You say “read/write buffer management can be tricky to achieve good performance”. I can’t figure out what do you mean here. That bulk ByteBuffer.get() is faster than invoking ByteBuffer.get() for each byte? Or that it is easy to forget to call ByteBuffer.flip() ? That’s not tricky, in my opinion. You say “dealing with packet fragmentation is difficult”. That is also strange for me, because UDP re-assembles a datagram for you, and reading single data from TCP stream in several parts is not tricky at all. Buffer overflow ? But I see that read() and write() methods of channels check borders of ByteBuffers!

Then I say that I don’t like that task should be modified to fit into a framework, I meant that event-driven implementation is easier for me to do manually, through Executor interface.

Just to convince you that my opinion deserves to be available, I will tell you why I’ve written this. I’m dealing with high-performance networking for 3 years already. Sometimes my collegues ask me: “what do you think about this library” ? So, I’ve spent my time and evaluated them. Just bloat. Too many classes. Too deep hierarchies. They don’t worth it.

By the way, maybe you know why Tomcat and James don’t use this library ?