Expand ChannelPipeline javadocs to cover UnorderedThreadPoolEventExecutor (#10361)
Motivation: Seems like some users are suprised by the behaviour of DefaultEventExecutor when used within the ChannelPipeline. We should clarify the semantics and also mention UnordedThreadPoolEventExecutor which may be more inline with their expectations Modifications: Add javadocs section about UnorderedThreadPoolEventExecutor and expand details for DefaultEventExecutor Result: Clarify sematics
This commit is contained in:
parent
8b3abf3b49
commit
e0dc054927
@ -18,6 +18,7 @@ package io.netty.channel;
|
||||
import io.netty.buffer.ByteBuf;
|
||||
import io.netty.util.concurrent.DefaultEventExecutorGroup;
|
||||
import io.netty.util.concurrent.EventExecutorGroup;
|
||||
import io.netty.util.concurrent.UnorderedThreadPoolEventExecutor;
|
||||
|
||||
import java.net.SocketAddress;
|
||||
import java.nio.ByteBuffer;
|
||||
@ -207,6 +208,11 @@ import java.util.NoSuchElementException;
|
||||
* pipeline.addLast(group, "handler", new MyBusinessLogicHandler());
|
||||
* </pre>
|
||||
*
|
||||
* Be aware that while using {@link DefaultEventLoopGroup} will offload the operation from the {@link EventLoop} it will
|
||||
* still process tasks in a serial fashion per {@link ChannelHandlerContext} and so guarantee ordering. Due the ordering
|
||||
* it may still become a bottle-neck. If ordering is not a requirement for your use-case you may want to consider using
|
||||
* {@link UnorderedThreadPoolEventExecutor} to maximize the parallelism of the task execution.
|
||||
*
|
||||
* <h3>Thread safety</h3>
|
||||
* <p>
|
||||
* A {@link ChannelHandler} can be added or removed at any time because a {@link ChannelPipeline} is thread safe.
|
||||
|
Loading…
Reference in New Issue
Block a user