For more context, I am using gRPC 1.55.1. We are calling gRPC services like
below
gRPC1 --> gRCP2 -> HttpServer
If the HttpServer is not available then from gRPC2 server Status.UNAVAILABLE
error is thrown with some Metadata as shown below. But we are observing
that sometimes the Metadata is not coming to gRPC1. It does not happen
always. Most of the time gRPC1 receives the Status.UNAVAILABLE along with
the Metadata. Can someone let me know if there are some known issues with
gRPC 1.55.1 or it could be due to responseObserver.onError() not done in a
try-catch in the gRPC server's purge() method as suggested by Eric in this
thread.
gRPC2
-----------
public void purge(
final PurgeRequest request, final StreamObserver<PurgeResponse>
responseObserver) {
validator.validate(request);
responseObserver.onNext(service.purge(request));
responseObserver.onCompleted();
}
class Service {
void purge() {
try {
// http call
} catch(Http Service Not available) {
var metadata = new Metadata();
// Add some data in metadata
throw new StatusRunTimeException(Status.UNAVAILABLE, metadata);
}
}
}
On Saturday 13 April 2024 at 21:53:06 UTC+5:30 Debraj wrote:
> Thanks for replying.
>
> I did not quite understand the statement - "*It will respond
> with Status.UNKNOWN and interceptors might get confused"* .
>
> Let's say I do not have the try - catch in the purge() method and I have
> a ServerInterceptor like below. Are you saying that the
> statusException.getStatus()
> in the below code may be Status.UNKNOWN sometime even if the
> validator.validate() is throwing StatusRunTImeException with some
> different Status. In that case statusException.getTrailers() can also be
> null or empty?
>
> public class ServerInterceptor implements io.grpc.ServerInterceptor {
> public < ReqT, RespT > ServerCall.Listener < ReqT > interceptCall(
> final ServerCall < ReqT, RespT > call,
> final Metadata requestHeaders,
> final ServerCallHandler < ReqT, RespT > next) {
> return new SimpleForwardingServerCallListener < >
> (next.startCall(grpcServerCall, requestHeaders)) {
> public void onMessage(final ReqT message) {
> try {
> // do something
> super.onMessage(message);
> } catch (Exception e) {
> handleException(ex);
> throw ex;
> }
> }
> // Similiar logic for onReady(), onHalfClose(), onComplete(),
> // where in a try .. catch handleException() & throw ex
> private void handleException(final Exception exception) {
> if (exception instance of StatusRunTimeException statusException) {
> val metadata = statusException.getTrailers();
> log.error("Request failed with metadata={}", metadata,
> statusException);
> call.close(statusException.getStatus(),
> ObjectUtils.defaultIfNull(metadata, new Metadata()));
> return;
> }
> call.close(Status.UNKNOWN.withDescription(exception.getMessage()),
> requestHeaders);
> }
> }
> }
> }
>
> On Friday 12 April 2024 at 03:21:52 UTC+5:30 Eric Anderson wrote:
>
>> If validator.validate() and service.purge() can throw, then you want a
>> try-catch. You must call onCompleted() or onError() on the observer for the
>> RPC to complete (and thus release its memory). gRPC does have some handling
>> for exceptions thrown by the service method, but it is a worst-case backup.
>> It will respond with Status.UNKNOWN and interceptors might get confused.
>>
>> If you are very concerned, you can catch exceptions from onNext(). In
>> general code tends to assume onNext() won't throw (or rather, won't throw
>> randomly; it will totally throw if you use it incorrectly, like calling it
>> after onCompleted()). So that's why the Hello World example server doesn't
>> have a try-catch.
>>
>> On Thu, Apr 11, 2024 at 1:55 PM Debraj <[email protected]> wrote:
>>
>>> If I have a code like below on a Java-based gRPC service
>>>
>>> @Override
>>> public void purge(
>>> final PurgeRequest request, final StreamObserver<PurgeResponse>
>>> responseObserver) {
>>> validator.validate(request);
>>> responseObserver.onNext(service.purge(request));
>>> responseObserver.onCompleted();
>>> }
>>>
>>> Is it recommended that I catch the exception and call onError() like
>>> below or it is not recommended? Is there any advantage of one approach over
>>> the other?
>>>
>>> @Override
>>> public void purge(
>>> final PurgeRequest request, final StreamObserver<PurgeResponse>
>>> responseObserver) {
>>> try {
>>> validator.validate(request);
>>> responseObserver.onNext(gdprService.purge(request));
>>> responseObserver.onCompleted();
>>> } catch (final Exception e) {
>>> log.error("Failed to purge {}", request, e);
>>> responseObserver.onError(e);
>>> }
>>> }
>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "grpc.io" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to [email protected].
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/grpc-io/985e6aee-2de0-4ca4-b99e-f17e61297cc5n%40googlegroups.com
>>>
>>> <https://groups.google.com/d/msgid/grpc-io/985e6aee-2de0-4ca4-b99e-f17e61297cc5n%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>
--
You received this message because you are subscribed to the Google Groups
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/grpc-io/61fc0d45-09df-4551-aedf-3867bcf0387en%40googlegroups.com.
