his is the first part of a new interview series that's focusing on event-driven solutions on the JVM.
Norman Maurer is the Tech Lead of the popular Netty library and also a core committer on the vert.x project. (His book about Netty will be released on Manning later this year.)
First of all, congrats on the release of Netty4 and Vert.x 2.0!
thanks!
Let's start with Netty4
alright...
There are many things to like here. I really dig the modularization changes as well as the fact that ChannelHandlers are firing up fewer events
yeah... we had some issues because of the heavy event creation GC-pressure and such, so we thought it was about time to fix it
Other than Vert.x, are you aware of any other Netty4 based projects? Personally, I would love to see more real-world examples.
There are other projects that started to port their codebases to Netty4, too. But obviously most of them are still in early stages...
The reason why I am asking is that it's clear to me Netty4 is a huge step forward (new Buffer handling, ChannelFuture-s, easier resource management, leak detection etc.) but I can imagine that the migration might be tricky
ok so let me try to give some detail... Vert.x is kind of the pioneer here.. Which is no surprise as I'm also part of the team which works on Vert.x. The next project I know of which will migrate to Netty4 is HornetQ.
There are also other smaller projects out there which seem to get attracted by the new features but even for them, it's still some kind of a slow migration. I guess it's because of the heavy API breakage and we still need to make the documentation better. It's one of our weak areas. I hope things will be better with my book (but as you know, it's still in the making).
Overall, I think it's easier for newcomers but harder for old users as they need to wrap their head around the new concepts. For example, I am pretty sure netty3 users will need to spend some time with understanding why buffers are now pooled. Also, whose responsibility is it to release them? (Without explicit release, you will get an OOM soon.)
This change happened for a good reason, though: our benchmarks show that comparing using pooled buffers vs un-pooled buffers in Vert.x we get about 10% speed-up with the new implementation.
You mentioned that you rethought resource handling, so who's responsible to release the buffer then? It's done by the pool?
nope.. Basically it's done like this: for inbound traffic, netty's transport acquires a buffer out of the pool then it passes the buffer through the pipeline. Then in the pipeline there are ChannelInboundHandler implementations which receive the buffer - the last handler in the pipeline needs to release it.
...and so the new leak detector is going to catch a leak if the release does not happen?
our encoder and decoder automatically release a buffer once it was encoded/decoded completely, then we also have SimpleChannelInboundHandler which automatically releases every received buffer. In contrast, ChannelInboundHandlerAdapter does not do this for you, so most of the time, what you really want is SimpleChannelInboundHandler. The only time this may not be true if you wanted to operate on a ByteBuf or in the case of writing the same buffer back to the channel (like an echo server or proxy).
In case of outbound (a.k.a write) traffic, the buffer is released as soon as it is completely written to the channel - this is done by Netty's transport implementation.
And yeah, the leak detector would detect this and log a warning.
I see.
Let's change the topic slightly. If I needed to build say an evented HTTP server, should I adapt Netty4 or Vert.x as the foundation for that? I can imagine situations where both projects would be a good fit
Well, Netty is more low-level than Vert.x.
Assuming sockJs hits Netty4. Should I use that over Vert.x's implementation?
I see where you are heading. I guess it's just a matter of taste in some situations. Vert.x has a lot more to offer than Netty. If you don't need all of those add-ons, it may be better for you to just use Netty and have less dependencies etc. Vert.x really shines if you need a richer API and abstractions to write event-driven apps and also if you want to go polyglot. Netty, on the other hand, is more raw.
Looks like the module system has improved a lot in Vert.x 2.0. Can you tell us a bit about the new structure? I was particularly excited to see that now you can store your modules in maven repos.
ok... we tried to slim down the core of Vert.x a lot and make everything pluggable via modules. Before, different language API-s were heavily tied into the core, now everything is a module which makes it a lot easier for end users to write re-usable components.
The whole idea about the modules was to offer something similar to what node.js does, which allows users to register their modules easily.
All of these are very welcome changes for sure!
I really hope to see the Scala and Clojure support complete soon. We have someone in the community who even started to work on a PHP lang module as well.
Are the language modules wrapping around the end user API or they are accessing something closer to the metal?
The language modules are just a wrapper around the Java API
...and as for custom modules, are those polyglot, too?
For custom modules you can depend on whatever other module you want too... so yes. The runnable modules communicate over the EventBus (JSON) so you can use a module and not care about in which language it was written.
I found the polyglot story interesting but to be honest, I have some reservations. In my experience, maintaining mixed projects (mixed in terms of languages) can be painful. Especially when the need of passing native data types arises
I think it is a matter of taste. I would, for example, only choose one language and stick with it when working on a project but if you split your project into different modules, you can mix things easily. For example, one team could work on a db driver and write it in JavaScript as all of them are js devs, another team would work on the core backend but use the db driver via the EventBus (JSON) and even not knowing that it was written in JavaScript. So mainly the polyglot thingy gives everyone freedom and still allows easy reuse.
Yeah - I certainly can see different JVM langs interoperating on a service level (lots of companies are building on the JVM in this fashion i.e. Twitter, Netflix etc.) my comment was more about working within a single project.
I agree - mixed languages in one "module/service" can cause problems in term of maintenance. Personally I would choose one lang and stick with it per "service/module".
The new vert.x website characterizes the EventBus as "actor-like". Where do you think the difference is?
Well, Vert.x gives you all in one platform, with actor based system you still need to stick in your own HTTP server whatever like Spray does. So I see Vert.x more like a complete platform which allows to write async network code, potentially using multiple languages.
I saw a few community projects popping up on the mailing list
Yep. We got a few now...
Can you name a few 3rd party extensions that you are particularly fond of?
The one I really find interesting, which is still in active development, is a module which provides async mysql/postgresql access without using JDBC at all. Db access is still a big problem in the async world.
Yeah, totally. That's a big pain point...
In fact, I just started to port the original code to Netty4 to make sure it is run on the same EventLoop as Vert.x.
The other interesting project I'm waiting for is an async DNS codec. We actually want to make use of this DNS solution in a vert.x module.
I also saw some activities around RxJava support. Are you planning any official module for that?
We are working on it ;)
While we are at modules, I remember seeing a web framework/middleware on top of Vert.x, too
yeah that's called Yoke.
Do you see Vert.x as an end user library or folks should see it as higher abstraction than Netty but lower than say Play?
Basically what we want to offer with Vert.x is an easy way to write network services which can scale and everything on top should go in modules. We hope to make it easy to implement extra features as modules and register them in our module registry.
I was quite surprised to see that vert.x embed got some extra support in 2.0. When we talked about Vert.x a while back, the future of the embedding feature was less clear...
haha... I think one of the really hot things in this area is the .js support
Do you guys plan to have anything special for Nashorn?
We have licensing issues with Nashorn [Nashorn is under GPL2] which is unfortunate.
But what quite interesting in JavaScript land is a node.js module which allows you to write node.js apps on top of Vert.x. It's still work-in-progress but it will provide a relatively easy migration path. Vert.x really out-performs node.js in many ways.
My final questions are about the whole event-driven space which seems to be booming these days.
What do you think about Reactor?
Reactor uses Netty [for their TCPServer/Client implementation], so I'm in contact with them. I think this space is indeed really hot at the moment and we will surely see a lot of traction in the future. The problem is that there are still a lot of legacy libraries around which slow things down.
Jonas Bonér from Typesafe was pushing for a shared vocabulary. Any thoughts on this initiative?
Yeah the manifesto ... To be honest, I think it's nothing new.. In fact, many frameworks do exactly what is written there. For example, all the event related attributes he mentions were also implemented in Netty 3. Vert.x also fits into this paradigm quite well.
What other collaborations can you imagine between these various projects (Vert.x, RxJava, Akka, Netty, Finagle, Reactor etc. etc.)?
Finagle is built on top of Netty - so obviously there is collaboration there already. Same for Play [although Play may switch to akka-io at some point but we'll see]. As for Reactor, I helped them with their Netty-based TCP implementation.
Well, that was it. Thanks for your time!
Thank you.