Commit Graph

51 Commits

Author SHA1 Message Date
Norman Maurer
aa8bdb5d6b Fix assertion error when closing / shutdown native channel and SO_LINGER is set.
Motivation:

When SO_LINGER is used we run doClose() on the GlobalEventExecutor by default so we need to ensure we schedule all code that needs to be run on the EventLoop on the EventLoop in doClose. Beside this there are also threading issues when calling shutdownOutput(...)

Modifications:

- Schedule removal from EventLoop to the EventLoop
- Correctly handle shutdownOutput and shutdown in respect with threading-model
- Add unit tests

Result:

Fixes [#7159].
2017-09-18 14:46:37 -07:00
Scott Mitchell
89ecb4b4a4 AutoClose behavior may infinite loop
Motivation:
If AutoClose is false and there is a IoException then AbstractChannel will not close the channel but instead just fail flushed element in the ChannelOutboundBuffer. AbstractChannel also notifies of writability changes, which may lead to an infinite loop if the peer has closed its read side of the socket because we will keep accepting more data but continuously fail because the peer isn't accepting writes.

Modifications:
- If the transport throws on a write we should acknowledge that the output side of the channel has been shutdown and cleanup. If the channel can't accept more data because it is full, and still healthy it is not expected to throw. However if the channel is not healthy it will throw and is not expected to accept any more writes. In this case we should shutdown the output for Channels that support this feature and otherwise just close.
- Connection-less protocols like UDP can remain the same because the channel may disconnected temporarily.
- Make sure AbstractUnsafe#shutdownOutput is called because the shutdown on the socket may throw an exception.

Result:
More correct handling of write failure when AutoClose is false.
2017-08-25 21:01:41 -07:00
Scott Mitchell
cf171ff525 maxBytesPerRead channel configuration
Motiviation:
The current read loops don't fascilitate reading a maximum amount of bytes. This capability is useful to have more fine grain control over how much data is injested.

Modifications:
- Add a setMaxBytesPerRead(int) and getMaxBytesPerRead() to ChannelConfig
- Add a setMaxBytesPerIndividualRead(int) and getMaxBytesPerIndividualRead to ChannelConfig
- Add methods to RecvByteBufAllocator so that a pluggable scheme can be used to control the behavior of the read loop.
- Modify read loop for all transport types to respect the new RecvByteBufAllocator API

Result:
The ability to control how many bytes are read for each read operation/loop, and a more extensible read loop.
2015-08-05 23:59:54 -07:00
Norman Maurer
869687bd71 Port ChannelOutboundBuffer and related changes from 4.0
Motivation:

We did various changes related to the ChannelOutboundBuffer in 4.0 branch. This commit port all of them over and so make sure our branches are synced in terms of these changes.

Related to [#2734], [#2709], [#2729], [#2710] and [#2693] .

Modification:
Port all changes that was done on the ChannelOutboundBuffer.

This includes the port of the following commits:
 - 73dfd7c01b
 - 997d8c32d2
 - e282e504f1
 - 5e5d1a58fd
 - 8ee3575e72
 - d6f0d12a86
 - 16e50765d1
 - 3f3e66c31a

Result:
 - Less memory usage by ChannelOutboundBuffer
 - Same code as in 4.0 branch
 - Make it possible to use ChannelOutboundBuffer with Channel implementation that not extends AbstractChannel
2014-08-05 15:00:45 +02:00
Trustin Lee
96b0a949e1 Make most outbound operations cancellable / More robust promise update
- Inspired by #2214 by @normanmaurer
- Call setUncancellable() before performing an outbound operation
- Add safeSetSuccess/Failure() and use them wherever
2014-02-10 14:57:18 -08:00
Trustin Lee
bcef796dc7 Rewrite ChannelOutboundBuffer
- Merge MessageList into ChannelOutboundBuffer
- Make ChannelOutboundBuffer a queue-like data structure so that it is nearly impossible to leak a message
- Make ChannelOutboundBuffer public so that AbstractChannel can expose it to its subclasses.
- TODO: Re-enable gathering write in NioSocketChannel
2013-07-18 20:59:14 +09:00
Norman Maurer
2871079c4a [#1557] Make the contract of Channel.Unsafe.flush() more clear
* Remove boolean parameter from Channel.Unsafe.flush() method
* Move NIO related things to AbstractNioChannel.NioUnsafe
2013-07-12 19:45:31 +02:00
Trustin Lee
99716993f6 Add a boolean parameter to Channel.Unsafe.flush() so that SelectionKey state check can be bypassed. 2013-07-12 20:14:50 +09:00
Jeff Pinner
224f05e626 Use correct permission mode for java files 2013-07-10 21:58:12 +02:00
Norman Maurer
b57d9f307f Allow per-write promises and disallow promises on flush()
- write() now accepts a ChannelPromise and returns ChannelFuture as most
  users expected.  It makes the user's life much easier because it is
  now much easier to get notified when a specific message has been
  written.
- flush() does not create a ChannelPromise nor returns ChannelFuture.
  It is now similar to what read() looks like.
2013-07-11 00:49:48 +09:00
Trustin Lee
cbd8817905 Remove MessageList from public API and change ChannelInbound/OutboundHandler accordingly
I must admit MesageList was pain in the ass.  Instead of forcing a
handler always loop over the list of messages, this commit splits
messageReceived(ctx, list) into two event handlers:

- messageReceived(ctx, msg)
- mmessageReceivedLast(ctx)

When Netty reads one or more messages, messageReceived(ctx, msg) event
is triggered for each message.  Once the current read operation is
finished, messageReceivedLast() is triggered to tell the handler that
the last messageReceived() was the last message in the current batch.

Similarly, for outbound, write(ctx, list) has been split into two:

- write(ctx, msg)
- flush(ctx, promise)

Instead of writing a list of message with a promise, a user is now
supposed to call write(msg) multiple times and then call flush() to
actually flush the buffered messages.

Please note that write() doesn't have a promise with it.  You must call
flush() to get notified on completion. (or you can use writeAndFlush())

Other changes:

- Because MessageList is completely hidden, codec framework uses
  List<Object> instead of MessageList as an output parameter.
2013-07-09 23:51:48 +09:00
Trustin Lee
7396f9f2b2 Remove Channel.id completely / Use 64-bit hashCode internally to reduce the chance of collision in compareTo() 2013-07-09 14:49:06 +09:00
Trustin Lee
734ec51ac9 Allow specifying 0 as the default number of threads when instantiating an EventLoopGroup
- Fixes #1426
- We already allow a user instantiate an EventLoopGroup with the default number of threads via the default constructor, so I think it's OK although it's not always optimal.
2013-06-27 10:39:39 +09:00
Trustin Lee
14158070bf Revamp the core API to reduce memory footprint and consumption
The API changes made so far turned out to increase the memory footprint
and consumption while our intention was actually decreasing them.

Memory consumption issue:

When there are many connections which does not exchange data frequently,
the old Netty 4 API spent a lot more memory than 3 because it always
allocates per-handler buffer for each connection unless otherwise
explicitly stated by a user.  In a usual real world load, a client
doesn't always send requests without pausing, so the idea of having a
buffer whose life cycle if bound to the life cycle of a connection
didn't work as expected.

Memory footprint issue:

The old Netty 4 API decreased overall memory footprint by a great deal
in many cases.  It was mainly because the old Netty 4 API did not
allocate a new buffer and event object for each read.  Instead, it
created a new buffer for each handler in a pipeline.  This works pretty
well as long as the number of handlers in a pipeline is only a few.
However, for a highly modular application with many handlers which
handles connections which lasts for relatively short period, it actually
makes the memory footprint issue much worse.

Changes:

All in all, this is about retaining all the good changes we made in 4 so
far such as better thread model and going back to the way how we dealt
with message events in 3.

To fix the memory consumption/footprint issue mentioned above, we made a
hard decision to break the backward compatibility again with the
following changes:

- Remove MessageBuf
- Merge Buf into ByteBuf
- Merge ChannelInboundByte/MessageHandler and ChannelStateHandler into ChannelInboundHandler
  - Similar changes were made to the adapter classes
- Merge ChannelOutboundByte/MessageHandler and ChannelOperationHandler into ChannelOutboundHandler
  - Similar changes were made to the adapter classes
- Introduce MessageList which is similar to `MessageEvent` in Netty 3
- Replace inboundBufferUpdated(ctx) with messageReceived(ctx, MessageList)
- Replace flush(ctx, promise) with write(ctx, MessageList, promise)
- Remove ByteToByteEncoder/Decoder/Codec
  - Replaced by MessageToByteEncoder<ByteBuf>, ByteToMessageDecoder<ByteBuf>, and ByteMessageCodec<ByteBuf>
- Merge EmbeddedByteChannel and EmbeddedMessageChannel into EmbeddedChannel
- Add SimpleChannelInboundHandler which is sometimes more useful than
  ChannelInboundHandlerAdapter
- Bring back Channel.isWritable() from Netty 3
- Add ChannelInboundHandler.channelWritabilityChanges() event
- Add RecvByteBufAllocator configuration property
  - Similar to ReceiveBufferSizePredictor in Netty 3
  - Some existing configuration properties such as
    DatagramChannelConfig.receivePacketSize is gone now.
- Remove suspend/resumeIntermediaryDeallocation() in ByteBuf

This change would have been impossible without @normanmaurer's help. He
fixed, ported, and improved many parts of the changes.
2013-06-10 16:10:39 +09:00
Trustin Lee
fd1d31e7d8 Remove unnecessary inEventLoop() checks in Channel.Unsafe
.. because HeadHandler in the pipeline always ensures those methods are always invoked from the correct I/O thread
2013-05-17 19:20:46 +09:00
Norman Maurer
ba71e3dcd0 Don'T call ChannelPipeline.fireExceptionCaught(..) for outbound events 2013-02-11 07:19:40 +01:00
Norman Maurer
4e77bacdf7 [#873] [#868] Split ChannelFuture into ChannelFuture and ChannelPromise 2012-12-31 23:27:16 +09:00
Trustin Lee
0909878581 Read only when requested (read-on-demand)
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.
2012-12-31 23:26:00 +09:00
Norman Maurer
ef555d268c Add more javadocs and replace some abstract methods with noops as we often implemented them as noops 2012-12-21 17:06:24 +01:00
Trustin Lee
def12a171c Rename ChannelBuf to Buf and ChannelBufType to BufType
- Fixes #825
2012-12-17 17:43:45 +09:00
Trustin Lee
33c0c89fef Remove unnecessary empty lines 2012-12-03 19:58:13 +09:00
Trustin Lee
818a7b42a3 Fix all Xlint:unchecked warnings 2012-11-30 22:49:51 +09:00
Trustin Lee
b25996d024 [#486] Make NoSuchBufferException give more useful message.
- Remove confusing exception messages
- Do not use default exception messages wherever possible
2012-08-20 21:03:23 +09:00
norman
8b473dce6c Rename class 2012-07-30 15:07:12 +02:00
Norman Maurer
57e7255566 Add support to suspend reads. See #71 2012-07-27 20:02:47 +02:00
Trustin Lee
42380b54b3 Revert file mode 2012-07-07 14:39:35 +09:00
Trustin Lee
a5bb2c7f77 Add ChannelMetadata and remove unnecessary disconnect() impls
- 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
2012-07-07 14:30:24 +09:00
Norman Maurer
c165a38e15 Revert as it should be in nio2 branch "Commit first round of classes to support nio2/async channel api. Still work in progress.. See #396"
This reverts commit 18aaae3c2e.
2012-07-07 14:30:24 +09:00
Norman Maurer
f8ef5d5d78 Next round for async channel api support a.k.a nio2. See See #396 2012-06-14 21:02:47 +02:00
Norman Maurer
032912d938 Commit first round of classes to support nio2/async channel api. Still work in progress.. See #396 2012-06-13 22:24:16 +02:00
Trustin Lee
3b562c917d Move ChannelBufferType to netty-buffers and rename it to ChannelBufType
- Also add ChannelBuf.type()
2012-06-12 17:05:28 +09:00
Trustin Lee
ecd0ae5406 Prefer MessageBuf over Queue where possible
- Also replaced thread safe queues with non-thread-safe ones where
  possible
- Unpooled.wrappedBuffer(Queue<T>) does not wrap MessageBuf anymore
2012-06-12 17:02:00 +09:00
Trustin Lee
9dce123938 Use MessageBuf instead of Queue wherever possible in channel API 2012-06-11 10:43:47 +09:00
Trustin Lee
5164d91255 Rename ChannelBuffer to ByteBuf as discussed before
- 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.
2012-06-10 11:08:43 +09:00
Trustin Lee
24e1f936a8 ChannelType -> ChannelBufferType / Optimize DefaultChannelPipeline
- Channel.type() -> bufferType()
- Use simpler bit mask operation for pipeline traversal
2012-06-09 09:44:30 +09:00
Trustin Lee
994038975a Port HttpContentEncoder/Decoder to use EmbeddedStreamChannel / Cleanup
- Removed unused constructor parameter in AbstractChannel
- Re-enabled GZIP encoding in HTTP snoop example
2012-06-07 21:06:56 +09:00
Trustin Lee
5e93d206ff Overhaul - Split ChannelHandler & Merge ChannelHandlerContext
- 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
2012-06-07 14:52:33 +09:00
Trustin Lee
1eced1e9e3 Update license headers 2012-06-04 13:31:44 -07:00
Trustin Lee
01a5bd41f0 Add Channel.type() which tells if stream-oriented or message-oriented
- 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.
2012-06-02 01:58:15 -07:00
Trustin Lee
141a05c831 Strict thread model / Allow assign an executor to a handler
- 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
2012-06-01 17:51:19 -07:00
Trustin Lee
a53ecbf5f1 Implement the local transport
- Replace the old local example with localecho example
- Channel's outbound buffer is guaranteed to be created on construction
  time.
2012-05-30 03:58:14 -07:00
Trustin Lee
f4c6bcafaf Keep channel's outbound buffer in AbstractChannel
- Replace firstOut() with newOutboundBuffer()
2012-05-30 00:35:53 -07:00
Trustin Lee
026715e818 Refactor the pipeline API to support stacked codecs
- 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()
2012-05-29 12:09:29 -07:00
Trustin Lee
6206d82b2c Split AbstractChannel into AbstractOioChannel and AbstractNioChannel
- Simpler OIO transport
- Suits better for other transports such as AIO, RXTX, IOStream
- Add ChannelBufferHolders.discardBuffer()
2012-05-26 22:48:48 -07:00
Trustin Lee
61314ef51b Split AbstractChannel.doFlush() into two variants for simpler user impl
- Also renamed doRead() to doReadMessages() and doReadBytes()
2012-05-25 15:32:28 -07:00
Trustin Lee
59f11ed64f Optimize AbstractChannel and related classes
- 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
-
2012-05-25 06:16:25 -07:00
Trustin Lee
6a0040a14e Fix compilation errors 2012-05-13 18:45:57 +09:00
Trustin Lee
129a2af86a Initial working version of the echo server example
- 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 :-)
2012-05-09 22:09:06 +09:00
Trustin Lee
607d784e5e Retrofit/overhaul the NIO transport with the new API
- Remove large portion of code thanks to the new API
- SocketChannel implementations are instantiated without factories
- Retrofit the existing code with the new API
2012-05-02 21:05:53 +09:00
Trustin Lee
368156f5d0 Another round of the new API design
- 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
2012-05-01 17:19:41 +09:00