Benjamin Peterson
Benjamin Peterson
What's the problem with using always using `gcc` as the compiler? It's perfectly capable of compiling C++.
Yes, the linking behavior is slightly different, but in a crosstool, there isn't really any harm in explicitly writing the `-lstdc++`.
`varref` has never been supported by Bazel.
This sort of warning already exists: https://github.com/bazelbuild/bazel/blob/86bc93563102fb410b308ede345beeb4be7bdd69/src/main/java/com/google/devtools/build/lib/actions/AbstractAction.java#L512-L538 It's just only enabled for `genrule`.
Thank you for your response. The reason I want to distinguish this case with a non-UNAVAILABLE status code is alerting. A busy dying client can cause 100s of UNAVAILABLE errors...
The case I saw is the client is killed by the Linux OOM killer. Then, the kernel closes all the client's TCP connections, leading the server to invoke the code...
> * In general, matching the status code the client sees is strongly preferable. Yes, there are times where the client and server would disagree, but this is a case...
> > The server is incapable of sending the client a status code because the connection is gone. How can the client and server status codes be said to match?...
How about adding an option to `NettyServerBuilder` to configure what error code is logged in this case?
The problem is mostly in `ServerStreamTracer`, which I believe is an API specific to grpc-java. E.g., https://github.com/grpc/grpc-java/issues/8684#issuecomment-967340827 says that grpc-go doesn't even trace a status for the unclean connection termination...