Repository navigation
NettyClientStream does not handle netty write data failure promise #10849
Description
Activity
- changed the title
[-]NettyClientStream does not handle netty write data failue promise[/-][+]NettyClientStream does not handle netty write data failure promise[/+]on Jan 25, 2024 Thank you for reporting this! Seems like an interesting case. I'm planning to take care of the issue in NettyClientStream.writeFrameInternal, and check for any other places this issue may affect.
If the stream ids are exhausted, then sending the headers should have failed, and we do have error handling for that. So this was only a problem because of a bug in Netty. That's why we've not really had error handling for sending; the only clear error is the connection dying.
yeah, the root cause is a netty bug, but i think it is better for grpc to handle this failure case at the same time, we should not suppose that netty never failure when sending data.
Reacted by Sergii Tkachenko- added a commit that references this issue
on Apr 16, 2024 - locked as resolved and limited conversation to collaborators
on Jul 16, 2024
What version of gRPC-Java are you using?
1.26.0 (latest version has the same problem)
What is your environment?
linux, jdk8
What did you expect to see?
grpc client throw a exception when netty write data frame failed
What did you see instead?
grpc client blocking stub hangs forever when netty StreamBufferingEncoder return an unexpected failure promise
Steps to reproduce the bug
when the client http2 stream id is exhausted(using Integer.MAX_VALUE), netty codec-http2 StreamBufferingEncoder#writeData return a failure promise unexpectly , more details in netty/netty#13805
but grpc NettyClientStream does not report the failure future, and the grpc blocking stub will block forever.