They both provide roughly the same functionality. Which one should I choose to develop my high-performance TCP server? What are the pros & cons?
Reference links:
Advertisement
Answer
While MINA and Netty have similar ambitions, they are quite different in practice and you should consider your choice carefully. We were lucky in that we had lots of experience with MINA and had the time to play around with Netty. We especially liked the cleaner API and much better documentation. Performance seemed better on paper too. More importantly we knew that Trustin Lee would be on hand to answer any questions we had, and he certainly did that.
We found everything easier in Netty. Period. While we were trying to reimplement the same functionality we already had on MINA, we did so from scratch. By following the excellent documentation and examples we ended up with more functionality in much, much less code.
The Netty Pipeline worked better for us. It is somehow simpler than MINAs, where everything is a handler and it is up to you to decide whether to handle upstream events, downstream events, both or consume more low-level stuff. Gobbling bytes in “replaying” decoders was almost a pleasure. It was also very nice to be able to reconfigure the pipeline on-the-fly so easily.
But the star attraction of Netty, imho, is the ability to create pipeline handlers with a “coverage of one”. You’ve probably read about this coverage annotation already in the documentation, but essentially it gives you state in a single line of code. With no messing around, no session maps, synchronization and stuff like that, we were simply able to declare regular variables (say, “username”) and use them.
But then we hit a roadblock. We already had a multi-protocol server under MINA, in which our application protocol ran over TCP/IP, HTTP and UDP. When we switched to Netty we added SSL and HTTPS to the list in a matter of minutes! So far so good, but when it came to UDP we realised that we had slipped up. MINA was very nice to us in that we could treat UDP as a “connected” protocol. Under Netty there is no such abstraction. UDP is connectionless and Netty treats it as such. Netty exposes more of the connectionless nature of UDP at a lower level than MINA does. There are things you can do with UDP under Netty than you can’t under the higher-level abstraction that MINA provides, but on which we relied.
It is not so simple to add a “connected UDP” wrapper or something. Given time constraints and on Trustin’s advice that the best way to proceed was to implement our own transport provider in Netty, which would not be quick, we had to abandon Netty in the end.
So, look hard at the differences between them and quickly get to a stage where you can test any tricky functionality is working as expected. If you’re satisfied that Netty will do the job, then I wouldn’t hesitate to go with it over MINA. If you’re moving from MINA to Netty then the same applies, but it is worth noting that the two APIs really are significantly different and you should consider a virtual rewrite for Netty – you won’t regret it!