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:
Norman Maurer 2020-06-23 09:28:34 +02:00 committed by GitHub
parent 8b3abf3b49
commit e0dc054927
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23

View File

@ -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.