- Replace ByteBufferBackedByteBuf with DirectByteBuf
- Make DirectByteBuf and HeapByteBuf dynamic
- Remove DynamicByteBuf
- Replace Unpooled.dynamicBuffer() with Unpooled.buffer() and
directBuffer()
- Remove ByteBufFactory (will be replaced with ByteBufPool later)
- Add ByteBuf.Unsafe (might change in the future)
- Removed VoidEnum because a user can now specify Void instead
- AIO: Prefer discardReadBytes to clear
- AIO: Fixed a potential bug where notifyFlushFutures() is not called
if flush() was requested with no outbound data
- Used reflection hack to dispatch the tasks submitted by JDK
efficiently. Without hack, there's higher chance of additional
context switches.
- Server side performance improved to the expected level.
- Client side performance issue still under investigation
- Add Channel.metadata() and remove Channel.bufferType()
- DefaultPipeline automatically redirects disconnect() request to
close() if the channel has no disconnect operation
- Remove unnecessary disconnect() implementations
- ChannelInboundHandler and ChannelOutboundHandler does not have a type
parameter anymore.
- User should implement ChannelInboundMessageHandler or
ChannelOutboundMessageHandler.
- Add MessageBuf which replaces java.util.Queue
- Add ChannelBuf which is common type of ByteBuf and ChannelBuf
- ChannelBuffers was renamed to ByteBufs
- Add MessageBufs
- All these changes are going to replace ChannelBufferHolder.
- ChannelBuffer gives a perception that it's a buffer of a
channel, but channel's buffer is now a byte buffer or a message
buffer. Therefore letting it be as is is going to be confusing.
- Also prohibited a user from overriding
ChannelInbound(Byte|Message)HandlerAdapter. If a user wants to do
that, he or she should extend ChannelInboundHandlerAdapter instead.
- In computing, 'stream' means both byte stream and message stream,
which is confusing.
- Also, we were already mixing stream and byte in some places and
it's better use the terms consistently.
(e.g. inboundByteBuffer & inbound stream)
- SslHandler always begins handshake unless startTls is true
- Removed issueHandshake property
- If a user wants to start handshake later, he/she has to add
SslHandler later.
- Removed enableRenegotiation property
- JDK upgrade fixes the security vulnerability - no need to complicate
our code
- Some property name changes
- getSSLEngineInboundCloseFuture() -> sslCloseFuture()
- Updated securechat example
- Added timeout for handshake and close_notify for better security
- However, it's currently hard-coded. Will make it a property later.
- Some tests like SpdySessionHandlerTest accesses outbound buffer
even before the outbound buffer is initialized by
AbstractEmbeddedChannel's subclasses, leading to NPE at <init>.
To fix this problem, subclasses now pass the outbound buffer as
a constructor parameter to AbstractEmbeddedChannel.
- Added EventExecutor.inEventLoop(Thread) and replaced executor identity
comparison in DefaultChannelPipeline with it - more elegant IMO
- Removed the test classes that needs rewrite or is of no use
- LoggingHandler now only logs state and operations
- StreamLoggingHandler and MessageLoggingHandler log the buffer content
- Added ChannelOperationHandlerAdapter
- Used by WriteTimeoutHandler
- Extracted some handler methods from ChannelInboundHandler into
ChannelStateHandler
- Extracted some handler methods from ChannelOutboundHandler into
ChannelOperationHandler
- Moved exceptionCaught and userEventTriggered are now in
ChannelHandler
- Channel(Inbound|Outbound)HandlerContext is merged into
ChannelHandlerContext
- ChannelHandlerContext adds direct access methods for inboud and
outbound buffers
- The use of ChannelBufferHolder is minimal now.
- Before: inbound().byteBuffer()
- After: inboundByteBuffer()
- Simpler and better performance
- Bypass buffer types were removed because it just does not work at all
with the thread model.
- All handlers that uses a bypass buffer are broken. Will fix soon.
- CombinedHandlerAdapter does not make sense anymore either because
there are four handler interfaces to consider and often the two
handlers will implement the same handler interface such as
ChannelStateHandler. Thinking of better ways to provide this feature
- DefaultChannelPipeline detects such cases and creates an object called
'bridge' that works as a man-in-the-middle to deal with a race
condition
- Slight performance drop is observed but still faster than v3.
Couldn't find much from a profiler yet.
- Previously, head was a volatile field which is null at the beginning.
While iterating over the pipeline, if the loop hits null, it called
Channel.Unsafe explicitly.
- Instead, I created an outbound handler that redirects all requests
to the unsafe and made it a final field of the pipeline.
- As a result, DefaultChannelPipeline code became much simpler.
- SocketTestCombination generates all possible test combinations of
socket transports.
- SocketEchoTest iterates over the combinations and runs all tests
using reflection.
- The handler you specify with initializer() is actually simply added
to the pipeline and that's all. It's ChannelInitializer which does
additional work. For example, a user can specify just a single
handler with initializer() and it will still work. This is especially
common for Bootstrap, so I renamed initializer to handler, which makes
more sense.
- DefaultChannelPipeline uses this information to reject invalid buffer
access in inbound(Message|Byte)Buffer. Otherwise, a user can access
a message buffer when the channel is stream-oriented.
- Because ChannelType cannot be both STREAM and MESSAGE, catch-all
buffer has been removed to avoid confusion and unexpected behavior
(it's already causing headache.)
- As a result, codec embedder needs rework.
... just like we do with byte arrays. toByteBuffer() and
toByteBuffers() had an indeterministic behavior and thus it could not
tell when the returned NIO buffer is shared or not. nioBuffer() always
returns a view buffer of the Netty buffer. The only case where
hasNioBuffer() returns false and nioBuffer() fails is the
CompositeChannelBuffer, which is not very commonly used and *slow*.
- Add EventExecutor and make EventLoop extend it
- Add SingleThreadEventExecutor and MultithreadEventExecutor
- Add EventExecutor's default implementation
- Fixed an API design problem where there is no way to get non-bypass
buffer of desired type
- Add ChannelHandlerContext.eventLoop() for convenience
- Bootstrap and ServerBootstrap handles channel initialization failure
better
- More strict checks for missing @Sharable annotation
- A handler without @Sharable annotation cannot be added more than
once now.
- Added a new convenience method to ChannelInboundstreamHandlerAdapter
- EchoServerHandler uses the new method
- DefaultChannelPipeline calls inboundByteBuffer.discardReadBytes()
when it is sure there's no memory copy involved
- Really attempt to create a queue to determine LTQ can be initialized
in runtime, and cache the result
- Remove unnecessary Class<T> parameter in createQueue()
- Remove unused createQueue(Collection)
- LocalChannel and LocalServerChannel uses it to close themselves on
shutdown
- LocalEcho example does not call close() anymore because the channels
are closed automatically on shutdown
- Exception in this case makes a user less confusing
- To reduce the overhead of filling the stack trace,
NoSuchBufferException has a public pre-constructed instance.
- This is necessary because codec framework sometimes need to support
both type of outbound buffers.
- Fixed a bug where SpdyFrameEncoder did not handle ping messages
- Reduced memory copy in codec embedder (EmbeddedChannel)
- Renamed ChannelBootstrap to Bootstrap
- Renamed ServerChannelBootstrap to ServerBootstrap
- Moved bootstrap classes to io.netty.bootstrap as before
- Moved unfoldAndAdd() to a separate utility class
- Fixed a bug in unfoldAndAdd() where it did not handle ChannelBuffer
correctly
- Previous API did not support the pipeline which contains multiple
MessageToStreamEncoders because there was no way to find the closest
outbound byte buffer. Now you always get the correct buffer even if
the handler that provides the buffer is placed distantly.
For example:
Channel -> MsgAEncoder -> MsgBEncoder -> MsgCEncoder
Msg(A|B|C)Encoder will all have access to the channel's outbound
byte buffer. Previously, it was simply impossible.
- Improved ChannelBufferHolder.toString()
- AbstractChannel.doRead() is split into two versions so that the
implementation doesn't have to validate the buffer type.
- Optimized ChannelBufferHolder a little bit
- Reduced GC related with flush future notification
- Added FlushCheckpoint and DefaultChannelFuture implements it
opportunistically
-
- AbstractChannel now handles flushing a message buffer
- Cleaned up DatagramChannel interface
- Removed ProtocolFamily because a user can create an NIO
DatagramChannel and specify it as a constructor parameter
- UniqueName and UniqueKey constructors became public so that
I don't need to create a subclass every time.
- Replaced pipeline factories with initializers
- Ported essential parts related with HTTP to the new API
- Replaced ChannelHandlerAdapter.combine() with CombinedChannelHandler
- Fixed a bug where ReplayingDecoder does not notify the next handler
- Fixed a bug where ReplayingDecoder calls wrong callDecode() method
- Added a destination buffer as an argument to AbstractChannel.doRead()
for easier implementation
- Fixed a bug where NioSocketChannel did not try to increase the inbound
buffer size (moved the logic to AbstractChannel)
- UniqueKey removes the duplication between ChannelOption and
AttributeKey
- UniqueName provides common name collision check for AttributeKey,
ChannelOption, and Signal.
- Replaced ReplayError with Signal
