While work is ongoing to get the first beta out for our next major version, we also spend some time to fix bugs and add new features to our current stable tree.
And here you get them as part of Netty 3.6.0.Final.
The release includes bug-fixed, enhancements and also new features. So if you are interested keep reading.
As there was also a beta release of 3.6.0 before be sure to also read the notes for the beta release to have a complete list of the changes when come from an other release. You can find it in our previous blogpost.
Bugfixes
Like said we have a lot of bugfixes in there, here are the most important.
- [#775] AbstractNioWorker does not exit its event loop when the Executor is not an ExecutorService
- [#786] WebSocketServerHandshaker* may corrupt first WebSocket frame
- [#829] [#830] Fix a race in SslHandler which lead to handshake failure and other bad side-effects
New stuff and improvements
Add LineBasedFrameDecoder
Before when your application had to deal with line based protocols (like SMTP,Telnet etc) you usually used the DelimiterBasedFrameDecoder. This worked but was a big performance hit, as it is just over-designed for this kind of work.
Lucky enough we received a pull-request which introduced a new FrameDecoder just for line based protocols which performs a lot better.
Check the javadocs for all the constructors of LineBasedFrameDecoder.
To make it as easy as possible to get the performance improvement we do some conversation from DelimiterBasedFrameDecoder to LineBasedFrameDecoder if it is detected that a user use it with Delimiter.lineDelimiters(). This may get removed in the future so please update your code to use the new LineBaseFrameDecoder if you want to have the performance improvement in the long term 
For more informations on this change see [#759]
Support WebSocket 07
This release add support for WebSocket 07 to also allow to use Netty with old webbrowsers like Firefox 6. Even better you not need to change anything in your code-base. It will just be supported once you upgrade Netty.
Couldn't be easier, heh ?
For more details please see [#751].
Add BossPool to the party
Previous it was not possible to share the Boss instances that handle accept and connect operations. So if you needed to create a lot of different NioServerChannelFactory instances (or other NIO based ChannelFactory instances) you ended up with at least one needed Thread and Selector for each of them just for the Boss.
The can be wasteful and so we adapted the concept that we also used in the WorkerPool.
Now it is possible to use a BossPool when create them. This can make it a lot more resource friendly if you need to have a lot of them.
Anyway the old way of construct the ChannelFactory instances still work. So if you not want to make use of it and adjust your code just ignore this new feature.
Allow to shutdown ChannelFactory, Bootstrap, WorkerPool and BossPool
Before there was only one way to "shutdown" a ChannelFactory, Bootstrap, WorkerPool and BossPool. Most of the users just used the releaseExternalResources() for this. But sometimes this is problematic as you not want to release external resources like for example the Executor that is used by the ChannelFactory. For this purpose we now added a new method which is called shutdown(). With this it is possible to only shutdown() the instances and so "release" internal resources while still not affect resources that was passed in.
This makes it even more flexible to use Netty. For example you could now share the same ThreadPool with Netty and some other Component and not need to worry to affect each other when you not need the ChannelFactory anymore (just an example).
If you not need this you don't need to care of this change as releaseExternalResources() will take care of call shutdown() also.
For more details see [#790].
Allow to set a ThreadNameDeterminer per WorkerPool and BossPool
In previous version of Netty it was possible to set a ThreadNameDeterminer which is used for Netty to name your Threads that are used by the Worker and Boss and other places. Unfortunally it was only supported to set it via a static method, so once you change it it is used for all Netty "components" in your Application. This is often not what you want as sometimes you have a Server component and a Client component at the same time and would like to have it named differently to better identify the Threads which belongs to each of them.
Be aware that you can still set a static ThreadNameDeterminer which will just get overridden by the one that is specified in the BossPool and WorkerPool.
For more details see [#771].
Allow to specify a timeout for SslHandler.handshake()
When using SslHandler.handshake() it was impossible to set a timeout for this operation before it will fail. This could lead to the problem that the ChannelFuture which is returned by this operation will be notified only after it was detected that the remote peer is not there anymore. So you could wait for it like "forever" .
To fix this we added another constructor to SslHandler which allows you to specify and timeout for the handshake operation. If the handshake can not be completed within this time it will fail the handshake and so you get notified.
For more details see [#835].
General
For a complete list of changes please checkout our issue tracker. To download Netty, as usual, please visit the downloads page.
Please let us know if you have any problems or questions.