[
https://issues.apache.org/jira/browse/RATIS-2185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17895408#comment-17895408
]
Tsz-wo Sze commented on RATIS-2185:
-----------------------------------
bq. It is unfortunate that gRPC throws such an unclear message. We probably
should file a bug for the gRPC community.
The HTTP library used by gRPC, of course, is Netty. It seems that Netty
cancels the request when it exceeds the limit. Not sure if gRPC could get the
reason from Netty.
- See
https://github.com/grpc/grpc-java/blob/1993e68b038a3a9003374afc305c59b93532fa76/netty/src/main/java/io/grpc/netty/NettyClientHandler.java#L451
> Improve gRPC log messages debugability
> --------------------------------------
>
> Key: RATIS-2185
> URL: https://issues.apache.org/jira/browse/RATIS-2185
> Project: Ratis
> Issue Type: Improvement
> Components: gRPC
> Reporter: Duong
> Priority: Major
>
> Created this as a umbrella ticket for all changes related to improve the
> debugability of Ratis logs.
> Today, there're a couple of issues with ratis logs making debug issues in
> ratis a hard job. For example:
> * Lack of details: when an RPC call, e.g. appendEntries calls, fail, there
> is very little information to identify the problem, exception some vague
> message like "Unavailable" or "Client cancelled". We've seen examples where
> "Client cancelled" is displayed for technical problem in GRPC layer, e.g.
> when appendEntries buffers are bigger than the max GRPC acceptable message
> size.
> * Repetitive: TBF
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
