ctx.writeAndFlush throws BlockingOperationException even channel handler is in separate EventExecutorGroup
See original GitHub issueExpected behavior
BlockingOperationException only need to be thrown when calling await inside IO thread
Actual behavior
This is exception is thrown even when doing this:
ChannelInitializer(){
initChannel(...){
addLast(....)
addLast(eventExecutorGroup,"businessExecutor", new SimpleChannelInboundHandler(){
channelRead0(...){
val p = ctx.writeAndFlush(msg)
p.await()
}
})
}
}
Steps to reproduce
Minimal yet complete reproducer code (or URL to code)
Netty version
4.1.36
JVM version (e.g. java -version
)
OS version (e.g. uname -a
)
Issue Analytics
- State:
- Created 4 years ago
- Comments:15 (8 by maintainers)
Top Results From Across the Web
What causes BlockingOperationException in Netty 4?
ChannelPromise p = ctx.writeAndFlush(msg); p.await(). If add a handler in different EventExecutorGroup, this check is not necessary, ...
Read more >different thread in netty · Issue #8125 - GitHub
When I used thread is not in event loop, the ctx.write() will be packing to a task, but not execute now, when I...
Read more >FlushConsolidationHandler (Netty API Reference (4.0.56.Final))
The FlushConsolidationHandler should be put as first ChannelHandler in the ... public void flush(ChannelHandlerContext ctx) throws java.lang.Exception.
Read more >[1/2] GIRAPH-840: Upgrade to netty 4 (pavanka via majakabiljo)
+ public void channelActive(ChannelHandlerContext ctx) throws ... + ChannelHandler handler, String compareTo, EventExecutorGroup executor,
Read more >Chapter 6. ChannelHandler and ChannelPipeline - Netty in ...
Thus, if you number the handlers in figure 6.3 from left to right, the first ChannelHandler seen by an inbound event will be...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
@qeesung I think it is still necessary as you could still end up with a deadlock if another handler that is in from of the handler and uses the same
EventExecutorGroup
will delay the notification of the promise.@baijianhua As @normanmaurer said, If the same
EventGroupExecutor
is bound to different handlers on the same Pipeline, calling await can cause deadlock, although the thread calling await and the IO thread are not the same thread.Like the following
Instead, I recommend adding listener, or await it it in a custom thread (pool).