Is ServerCall#close guaranteed to be called for each RPC?

[ran...@addepar.com]

I am trying to track the number of RPCs that is being processed by server.

Is ServerCall#close guaranteed to be called for each RPC? 

Can I override ServerCall, increment counter in constructor and decrement the counter in #close?

[ran...@addepar.com]

I am using grpc-java 1.3.

[Eric Anderson]

ServerCall.close() is not guaranteed to be called, mainly in the case of cancellation. Either ServerCall.Listener.onCancel() or onComplete() is guaranteed to be called.

--
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 grpc-io+unsubscribe@googlegroups.com.
To post to this group, send email to grp...@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/f7af8f0e-795d-4a9a-b492-c5fe32290583%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Ran Bi]

Thanks Eric. 

I was under the impression that ServerCall.close also handle the cancellation because CANCELLED is declared in Status.Code.

Why is cancelation handled specially from other status?

On Mon, Jun 26, 2017 at 3:22 PM 'Eric Anderson' via grpc.io <grp...@googlegroups.com> wrote:

ServerCall.close() is not guaranteed to be called, mainly in the case of cancellation. Either ServerCall.Listener.onCancel() or onComplete() is guaranteed to be called.

On Mon, Jun 26, 2017 at 1:50 PM, ran.bi via grpc.io <grp...@googlegroups.com> wrote:

I am using grpc-java 1.3.

On Monday, June 26, 2017 at 11:32:45 AM UTC-7, ran...@addepar.com wrote:

I am trying to track the number of RPCs that is being processed by server.

Is ServerCall#close guaranteed to be called for each RPC? 

Can I override ServerCall, increment counter in constructor and decrement the counter in #close?

--
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 grpc-io+u...@googlegroups.com.

To post to this group, send email to grp...@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.

To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/f7af8f0e-795d-4a9a-b492-c5fe32290583%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "grpc.io" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/grpc-io/gWmvHo2WSdA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to grpc-io+u...@googlegroups.com.

To post to this group, send email to grp...@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.

To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/CA%2B4M1oO2k0PE%3D-sd5GdDm2d0y4vxtWBCNwObRoGEORe_XnX9Pw%40mail.gmail.com.

[Eric Anderson]

On Mon, Jun 26, 2017 at 4:10 PM, Ran Bi <ran...@addepar.com> wrote:

I was under the impression that ServerCall.close also handle the cancellation because CANCELLED is declared in Status.Code.

Why is cancelation handled specially from other status?

close() is for an application to tell gRPC to do something. In the case of error, that won't necessarily happen and gRPC can't guarantee it will be called, because gRPC isn't doing the calling.

If you do ServerCall.close(CANCELLED), if no other errors happen then onCompleted() will be called, as specified in the API:

If no errors or cancellations are known to have occurred, then a {@link Listener#onComplete} notification should be expected, independent of {@code status}.

So CANCELLED is not handled specially, since it is just a canonical status code; client-side cancellation and similar imply certain behaviors, and they will use CANCELLED, but that doesn't mean CANCELLED implies those behaviors. Client-side cancellation and similar is handled specially because the RPC is thrown away as quickly as possible and all messages discarded. close(CANCELLED) is graceful in that it waits for any queued messages to be sent before sending the close().

We have discussed before having server-side cancellation support, which throws away the RPC as quickly as possible. It'd have its use cases, but we were just going to wait until the strong need arose since we're doing other things that can more dramatically help our users.