Where is Netty heading?

[Aslak Hellesøy]

We have had a lot of netty related bugs lately.

What do people think - is Netty getting better or worse?

Aslak 

[peter hausel]

My take is that despite the weird bugs that I experienced with netty over time (sometimes even within minor releases) it is still one of the best choices on the JVM for implementing services that use various networking protocols. It's also very actively maintained and extremely well run OS project. So personally I like it a lot.  

[Kushal Pisavadia]

What do people think - is Netty getting better or worse?

Worse in terms of the webbit project's experience of using it, but better in the wider software eco-system.

My question back to you: What's the realistic alternative? Vertx?

Kind Regards,

Kushal Pisavadia
E: kus...@gmail.com

--
You received this message because you are subscribed to the Google Groups "Webbit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to webbit+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[peter hausel]

My question back to you: What's the realistic alternative? Vertx?

(vertx is using netty, too.)

[Joe Walnes]

Personally, I think Netty brings more pain than benefit to the project. It was a good starting point for the project because it had WebSocket decoders. But Aslak has reimplemented these anyway, and the cost of keeping up with Netty has been high, and I've found it more of a hindrance at times.

Last year I also spiked out using a JNI wrapped libuv based implementation. The majority of the code was written in C, with some high level Java bindings. It was much faster than the Netty backed implementation, used a single thread and was much better with memory and GC. It looked promising, but I decided to abort because adding C and JNI to the project brings in a lot of baggage both for the dev team maintaining the code on cross platforms, and for the Webbit users.

My choice would be to use java.nio sockets. It's not pretty, but you know exactly what's going on, it's pretty close to the operating system networking stack, it avoids any extra dependencies, and a lot more stable.

The only downside I can see for losing Netty is that Webbit would probably have to drop SSL support (it's a real pain trying to manage SSLEngine through a state machine - the Netty abstractions made it pretty easy). I'm ok with dropping that functionality, as I recommend using an HTTPS frontend offloader anyway (e.g. nginx, haproxy, stud, pound, stunnel, etc...).

-Joe

[aslak hellesoy]

On Wed, Apr 24, 2013 at 4:29 PM, Joe Walnes <j...@walnes.com> wrote:

Personally, I think Netty brings more pain than benefit to the project. It was a good starting point for the project because it had WebSocket decoders. But Aslak has reimplemented these anyway, and the cost of keeping up with Netty has been high, and I've found it more of a hindrance at times.

Netty is 3 things (according to http://netty.io/)

* Transport

* Core

* Protocols

If we could use Netty's Protocol support and perhaps the buffers, but do without the transport and threading stuff, I think we might be in a better place.

Is that worth trying?

 

Last year I also spiked out using a JNI wrapped libuv based implementation. The majority of the code was written in C, with some high level Java bindings. It was much faster than the Netty backed implementation, used a single thread and was much better with memory and GC. It looked promising, but I decided to abort because adding C and JNI to the project brings in a lot of baggage both for the dev team maintaining the code on cross platforms, and for the Webbit users.

Where is that code?

 

My choice would be to use java.nio sockets. It's not pretty, but you know exactly what's going on, it's pretty close to the operating system networking stack, it avoids any extra dependencies, and a lot more stable.

With a pure java.nio solution we'd still need a HTTP parser. Are you suggesting we write this from scratch then?

 

The only downside I can see for losing Netty is that Webbit would probably have to drop SSL support (it's a real pain trying to manage SSLEngine through a state machine - the Netty abstractions made it pretty easy). I'm ok with dropping that functionality, as I recommend using an HTTPS frontend offloader anyway (e.g. nginx, haproxy, stud, pound, stunnel, etc...).

Agree, Webbit shouldn't provide TLS in my opinion.

Aslak 

[aslak hellesoy]

On Wed, Apr 24, 2013 at 8:53 AM, Aslak Hellesøy <aslak.h...@gmail.com> wrote:

We have had a lot of netty related bugs lately.

What do people think - is Netty getting better or worse?

I just applied a patch to Webbit from one of the Netty developers:

https://github.com/webbit/webbit/pull/119

Awesome! Now we can use the latest Netty version.

Oh wait - a new Netty was released two days ago - 3.6.6.Final. Let's try that - it's just a patch version.

Guess what - that breaks Webbit again. org.webbitserver.handler.PostTest fails/hangs.

MEH

 

Aslak 

[Norman Maurer]

That's quite interesting... Let me have a look and find out why it breaks things. 

Bye,

Norman

[Norman Maurer]

Actual I know what commit / issue broke webbit. 

https://github.com/netty/netty/issues/1007

But I think the "fix" is correct here. Previously we was throwing a TooLongFrameException for each chunk that arrived which is bad for a few reasons, like:

* Performance as fillStackTrace() is quite slow/expensive

* It's not what users expect... They expect to get one exception per message.

So why your test fails with this fix in is not clear to me yet as I had no time to dig very deep in webbit. Maybe you have an idea or a guess ?