Perfect, thanks again. - Matt
On Tuesday, October 31, 2017 at 1:22:39 PM UTC-4, Carl Mastrangelo wrote: > > 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/7445b97e-1095-422c-8458-e5ca96f7ee06%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
