This change also introduce a few other changes which was needed:
* ChannelHandler.beforeAdd(...) and ChannelHandler.beforeRemove(...) were removed
* ChannelHandler.afterAdd(...) -> handlerAdded(...)
* ChannelHandler.afterRemoved(...) -> handlerRemoved(...)
* SslHandler.handshake() -> SslHandler.hanshakeFuture() as the handshake is triggered automatically after
the Channel becomes active
- Rename ChannelHandlerAdapter to ChannelDuplexHandler
- Add ChannelHandlerAdapter that implements only ChannelHandler
- Rename CombinedChannelHandler to CombinedChannelDuplexHandler and
improve runtime validation
- Remove ChannelInbound/OutboundHandlerAdapter which are not useful
- Make ChannelOutboundByteHandlerAdapter similar to
ChannelInboundByteHandlerAdapter
- Make the tail and head handler of DefaultChannelPipeline accept both
bytes and messages. ChannelHandlerContext.hasNext*() were removed
because they always return true now.
- Removed various unnecessary null checks.
- Correct method/field names:
inboundBufferSuspended -> channelReadSuspended
This pull request introduces a new operation called read() that replaces the existing inbound traffic control method. EventLoop now performs socket reads only when the read() operation has been issued. Once the requested read() operation is actually performed, EventLoop triggers an inboundBufferSuspended event that tells the handlers that the requested read() operation has been performed and the inbound traffic has been suspended again. A handler can decide to continue reading or not.
Unlike other outbound operations, read() does not use ChannelFuture at all to avoid GC cost. If there's a good reason to create a new future per read at the GC cost, I'll change this.
This pull request consequently removes the readable property in ChannelHandlerContext, which means how the traffic control works changed significantly.
This pull request also adds a new configuration property ChannelOption.AUTO_READ whose default value is true. If true, Netty will call ctx.read() for you. If you need a close control over when read() is called, you can set it to false.
Another interesting fact is that non-terminal handlers do not really need to call read() at all. Only the last inbound handler will have to call it, and that's just enough. Actually, you don't even need to call it at the last handler in most cases because of the ChannelOption.AUTO_READ mentioned above.
There's no serious backward compatibility issue. If the compiler complains your handler does not implement the read() method, add the following:
public void read(ChannelHandlerContext ctx) throws Exception {
ctx.read();
}
Note that this pull request certainly makes bounded inbound buffer support very easy, but itself does not add the bounded inbound buffer support.
- Also prohibited a user from overriding
ChannelInbound(Byte|Message)HandlerAdapter. If a user wants to do
that, he or she should extend ChannelInboundHandlerAdapter instead.
- 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
- 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.
- 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)
- Added ChannelBufferHolders.(inbound|outbound)BypassBuffer()
- The holder returned by these methods returns the next handler's
buffer. When a handler's new(Inbound|Outbound)Buffer returns
a bypass holder, your inboundBufferUpdated() and flush()
implementation should check if the buffer is a bypass and should not
modify the content of the buffer.
- Channel(Inbound|Outbound)?HandlerAdapter is now abstract.
- A user has to specify the exact inbound/outbound buffer type
- It's because there's no way to determine the best buffer type
- Implemented LoggingHandler using the new API.
- It doesn't dump received or sent messages yet.
- Fixed a bug where DefaultUnsafe.close() does not trigger deregister()
- Fixed a bug where NioSocketChannel.isActive() does not return false
when closed
- Optimized AbstractChannelBuffer.discardReadBytes()
- Split ChannelHandlerInvoker into ChannelInboundInvoker and
ChannelOutboundInvoker
- Channel implements ChannelOutboundInvoker
- ChannelOutboundInvoker.nextOut() is now out()
- ChannelOutboundHandlerContext.out() is now prevOut()
- Added the outbound operations without future
parameter to ChannelOutboundInvoker for user convenience
- All async operations which requires a ChannelFuture as a parameter
now returns ChannelFuture for user convenience
- Added ChannelFutureFactory.newVoidFuture() to allow a user specify
a dummy future that is of no use
- I'm unsure if it is actually a good idea to introduce it. It might
go away later.
- Made the contract of AbstractChannel.doXXX() much simpler and moved
all common code up to AbstractChannel.DefaultUnsafe
- Added Channel.isOpen()
- Fixed a bug where MultithreadEventLoop always shut down its child
event loops on construction
- Maybe more changes I don't remember :-)
- Channel now creates a ChannelPipeline by itself
I find no reason to allow a user to use one's own pipeline
implementation since I saw nobody does except for the cases where a
user wants to add a user attribute to a channel, which is now covered
by AttributeMap.
- Removed ChannelEvent and its subtypes because they are replaced by
direct method invocation.
- Replaced ChannelSink with Channel.unsafe()
- Various getter renaming (e.g. Channel.getId() -> Channel.id())
- Added ChannelHandlerInvoker interface
- Implemented AbstractChannel and AbstractServerChannel
- Some other changes I don't remember
- Rename ChannelReader to ChannelInboundHandler
- Rename ChannelWriter to ChannelOutboundHandler
- Introduce ChannelBufferHolder instead of adding the common super type
of message buffers and byte buffers
- This is more type-safe and natural.
- Remove the notification methods for buffer closure (might add back
later when revisiting half-closed connection support)
- Merged LifeCycleAwareChannelHandler into ChannelHandler
- Replaced ChannelUpstreamHandler and ChannelDownstreamHandler with
ChannelReader and ChannelWriter
- These two new interfaces are much more type-safe than its ancestor.
- Simplified channel state model as described in #68
- Handler creates send/receive buffer.
- Previously, Netty created them, but it led to more memory copies and
inflexibility. I'm going to allow a handler to create a bounded
queue for example.
- It currently uses Queue<T> but I'll define a new interface and make
ChannelBuffer implement it (e.g. Queue<Byte>)
- Introduced AttributeMap which replaces attachments in Channel and
ChannelHandlerContext and ChannelLocal
