Collectives™ on Stack Overflow

Find centralized, trusted content and collaborate around the technologies you use most.

Learn more about Collectives

Teams

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

Learn more about Teams

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:

Apache MINA ( source )

Netty ( source )

Grizzly is a completely different beast. There was even the idea of Grizzly support for MINA, when the both groups talked. – Hardcoded Nov 26, 2009 at 13:00 @Hardcoded you say grizzly is a completely different beast, I'm a new comer to this, can you please point out the differences or give me an article to read on that? I'd really appreciate it. – arg20 Jul 22, 2011 at 23:14 Grizzly has a different background and the last time I look at it, it was mostly suited to HTTP-based applications. I just looked at the examples and was surprised to see that they are using very similar structure as with MINA or Netty. So the beast isn't that different anymore – Hardcoded Aug 2, 2011 at 9:55

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!

re: earlier comment by Josh on lack of support for UDP in Netty: I don't understand why you couldn't use a few pages of hand-crafted code to do what you need, rather than abandoning Netty. UDP is listening on a different port anyway. I have been testing Netty vs. Nginx and am quite impressed (Netty scoring about the same, or better, under load). – user799282 Jun 15, 2011 at 9:16

Update: Just use Netty . It is now a mature project with all the bells and whistles required for building protocol clients and servers. It has strong community with several active contributors backed by enterprises. It also has a book, ' Netty in Action '. It has been adopted by many many well-known companies and projects already. Unlike Netty, Apache MINA has been under maintenance mode since I left the project.

MINA has more out-of-the-box features at the cost of complexity and relatively poor performance. Some of those features were integrated into the core too tightly to be removed even if they are not needed by a user. In Netty, I tried to address such design issues while retaining the known strengths of MINA.

Currently, most features available in MINA are also available in Netty. In my opinion, Netty has cleaner and more documented API since Netty is the result of trying to rebuild MINA from scratch and address the known issues. If you find that an essential feature is missing, please feel free to post your suggestion to the forum. I'd be glad to address your concern.

It is also important to note that Netty has faster development cycle. Simply, check out the release date of the recent releases. Also, you should consider that MINA team will proceed to a major rewrite, MINA 3, which means they will break the API compatibility completely.

@trustin, I found Netty 5.0 does not provide much advanced documents, and current web material with other version would not work. do you have any recommend link for intermediate and advanced mina tutorial? thanks – Korben Jun 10, 2015 at 1:13 @trustin is there an update you can make to this answer? MINA seems to have been mostly abandoned, and no MINA 3 was ever completed? – CausingUnderflowsEverywhere Aug 14, 2020 at 23:25

I performance tested 2 "Google Protobuffer RPC" implementations where one was based on Netty (netty-protobuf-rpc) and the other based on mina (protobuf-mina-rpc). Netty ended up being consistently faster ( +- 10% ) for all message sizes - which backs up the overall performance claim on the Netty web site. Since you want to squeeze every bit of efficiency out of your code when you use such an RPC library, i ended up writing protobuf-rpc-pro based on Netty. I have used MINA in the past, but find their documentation of the 2.0 stuff has big holes, and the breaking of API backward compatibility a big minus.

MINA and Netty were initially designed and build by the same author. That's why they are so similiar to each other. MINA is designed at a slightly higher level with a little more features, while Netty is a little faster. I think that there's not much difference at all, the basic concepts are the same.

In Netty site you can find some performance reports . As expected :-) they point out Netty as the framework with the best performance.

I never used Netty, but I already used MINA to implement a TCP protocol. The implementation of encoding and decoding was easy, but the implementation of the state machine was not so easy. MINA provides some classes to aid you when implementing the state machine, but I found them kind of hard to use. In the end we decided to ditch MINA and implement the protocol from scratch, and surprisingly we ended with a faster server.

I use Netty.

Twitter also chose Netty to build its new Search System and made it 3x faster.

Ref: Twitter Search is Now 3x Faster

We chose Netty over some of its other competitors, like Mina and Jetty, because it has a cleaner API, better documentation and, more importantly, because several other projects at Twitter are using this framework.

I've only ever used MINA to build a small http like server. The biggest problems I've run into with it so far:

It will hold your "request" and "response" in memory. This is only an issue because the protocol I choose to use is http. You could use your own protocol however to get around this.

No option to provide a stream off disk in case you want to serve up large files. Again can be worked around by implementing your own protocol

Nice things about it:

Can handle a lot of connections

If you choose to implement some sort of distributed work system then knowing when one of your nodes goes down and loses connection is useful for restarting the work on another node.