It's present on the ClientCall object, which are wrapped by StreamObservers. The ClientCall API is more advanced so most people don't use it. If you look at the generated stubs, you can see how to create a client call. All you need to do is not to wrap it in a StreamObserver.
On Tuesday, October 31, 2017 at 8:19:25 AM UTC-7, [email protected] wrote: > > Got it, thanks Carl - that helps a lot. Can you point me to an example of > how you'd call halfClose()? > > - Matt > > On Monday, October 30, 2017 at 8:45:17 PM UTC-4, Carl Mastrangelo wrote: >> >> Under the hood, the Client sends a RST_STREAM HTTP/2 frame with the >> cancelled error code. If you want to gracefully stop, you can send a >> halfClose() from the client and make the server interpret that as the end. >> Alternatively, you can try to send one last error message, and then call >> onError. >> >> The client and the server are asymmetric in this regard; the server can >> send back more detailed info, while the client cannot. >> >> On Monday, October 30, 2017 at 9:44:02 AM UTC-7, [email protected] >> wrote: >>> >>> OK I've answered one of my questions, which is that the Status exception >>> clearly states in the JavaDoc that it does not send the strack-trace with >>> the error. >>> >>> Looking more into the other question (how to properly send errors from >>> the client) - it seems as though no matter what error I send from the >>> client (using onError) - the server always gets a CANCELLED status, and no >>> details from the actual errors I send. This happens regardless of the type >>> of Status error - is this the correct behavior? >>> >>> - Matt >>> >>> On Friday, October 27, 2017 at 8:38:07 PM UTC-4, Matt Mitchell wrote: >>>> >>>> I have an application where the client establishes a bidirectional >>>> connection to the server, and the server begins sending requests to the >>>> client and vice versa. This app runs jobs, so that once a job starts, the >>>> messages flow back and forth from server to client and client to server. I >>>> would like to gracefully deal with exceptions thrown from the client. I'm >>>> not entirely sure if I should be calling onError for non-critical errors, >>>> or if I create a new Error message type and send via onNext. If I use >>>> onError, then the client needs to re-connect with a new Channel -- What is >>>> the better way to deal with this problem? Is there another way? >>>> >>>> Related question - for the Java impl of gRPC - is it possible to have >>>> the server log the stack trace of an error sent by the client via onError? >>>> I'm setting the cause on the io.grpc.Status instance, but it doesn't seem >>>> to be available on the receiving end. >>>> >>>> Thanks! >>>> - Matt >>>> >>> -- 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 post to this group, send email to [email protected]. 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/41f7bc62-edad-4126-b4f6-f55fe0579560%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
