[grpc-io] [C++] Get grpc::status of async bi-directional stream that was closed by server

[edelman . eric]

We have an async bi-directional streaming setup. We have implemented a 
health check on the stream and have logic where the server decides a client 
is stale or gone and closes the connection with that client. 

We have a Go server that is setting the error like so (I hope this is 
enough to give you an idea, I don't know the Go side at all...):
done <- errors.New(fmt.Sprintf("Server did not receive pong within 
grace period; subscription terminated"))

With a Python client, we get an exception on the stream correctly:
_Rendezvous: <_Rendezvous of RPC that terminated with 
(StatusCode.UNKNOWN, Server did not receive pong within grace period; 
subscription terminated)>

However, in C++ I cannot seem to get the above error output, which would 
help the client decide how to proceed.

What I have is a completion queue on which I call AsyncNext(). I can 
successfully get the 'ok' parameter to return false once the above 
termination happens. Reading through the docs and other posts here on 
groups it looks as though I then need to call Finish on my ReaderWriter 
object and that has an out param for a status. When I call that, it seems 
the status is never set and I also never see the tag I set for the Finish 
operation come through my completion queue. I have tried cancelling the 
stream from the client when this happens and that sets the status, but only 
to say that it was cancelled. 

A couple reasons I need the status code and status message: I want to be 
able to respond to different issues in different and appropriate ways. I 
read that AsyncNext setting 'ok' to false does not always mean there is an 
issue. 

Can someone help me connect these dots into the proper way to get the error 
messages from the server in this situation?

Thanks!
Eric Edelman

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to grpc-io@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/c2f907e0-ff25-47f8-9428-f4946362843c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [grpc-io] Sending headers on every message with bidirectional streaming?

['Kun Zhang' via grpc.io]

Sounds like you can just write a ServerInterceptor (which holds the Metrics 
object) to intercept ServerCall.Listener.onMessage() and 
ServerCall.Listener.onComplete()/onCancel() and do the stuff. I doesn't 
seem to involve Context (assuming you meant io.grpc.Context).

On Monday, September 25, 2017 at 3:30:59 PM UTC-7, thas@gmail.com wrote:
>
> Follow up question:
>
> In the same given scenario above, is it possible to have different 
> Contexts per message? The use case is that I'd like to have a metrics and 
> logging utility class on my server that is used to generate graphs and data 
> distributions using each call as a data point. So I'd like to pass around 
> this Metrics object across each call to do some unit of work on using its 
> member functions. 
>
>
> On Friday, September 22, 2017 at 11:56:16 AM UTC-7, thas@gmail.com 
> wrote:
>>
>> Ahh I see! Thank you very much
>>
>> On Friday, September 22, 2017 at 11:43:50 AM UTC-7, Josh Humphries wrote:
>>>
>>> Headers are per stream, not per message. The whole stream is a single 
>>> HTTP round-trip. So the first thing the server sends back are response 
>>> headers. Then the response payload (which consists of zero or more 
>>> messages). Finally, you get trailers.
>>>
>>> To include metadata for each response message, you'll have to encode 
>>> that into your RPC schema -- e.g. add a map field to your 
>>> response message (or whatever suits your need, the less stringly-typed 
>>> likely the better). Then your server can stuff that metadata into each 
>>> response message.
>>>
>>>
>>> 
>>> *Josh Humphries*
>>> jh...@bluegosling.com
>>>
>>> On Fri, Sep 22, 2017 at 2:36 PM,  wrote:
>>>

 So to send header metadata with on each call we can use interceptors. 
 Ex:
 https://github.com/grpc/grpc-java/blob/166108a9438c22d06eb3b371b5ad34a75e14787c/examples/src/main/java/io/grpc/examples/header/HeaderClientInterceptor.java

 However, for bidirectional streaming case for a given stub/channel, the 
 headers will only be sent once (via start() call). Is there a way to have 
 every message after to also have the headers sent? 

 I see that there is a sendMessage 
 https://github.com/grpc/grpc-java/blob/166108a9438c22d06eb3b371b5ad34a75e14787c/core/src/main/java/io/grpc/ServerCall.java#L128
  
 call, but it only takes in the request message as a parameter. So i'm 
 wondering if there's a way to send other parameters in the header on each 
 subsequent message call in the stream. 

 Of course, I could add the parameters to the message body, but that 
 could lead to a pretty large .proto definition. 

 Thanks!

 -- 
 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/32099406-cbbb-4e43-9821-9128faa34205%40googlegroups.com
  
 
 .
 For more options, visit https://groups.google.com/d/optout.

>>>
>>>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to grpc-io@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/c0d56a48-828d-4d60-ab97-d52e19ca1f8e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Re: Minimum and recommended pod requirements

['Kun Zhang' via grpc.io]

What's the memory and CPU usage when running on kubernetes compared with on 
your laptop?
Are they running at the same QPS in both environments?

On Wednesday, September 27, 2017 at 12:51:04 AM UTC-7, Ankur Chauhan wrote:
>
> Hi
>
> I'm running a grpc-java application in a kubernetes cluster on gke. This 
> application listens for request from the user, reads google cloud bigtable 
> over grpc using the official bigtable client and trouble with the rows 
> scanned with some simple parsing. It seems like whenever I run the server 
> process on my laptop with 8 cores and 4gb heap everything is really fast 
> but on the kubernetes cluster with resource sizes at 4 GB and 2 cores I 
> consistently see very high latencies in addition to long pauses in RPC. 
>
> Is there any guidance on what size pods I should run a grpc container. 
> What should I look for in terms of monitoring?
>
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to grpc-io@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/76b2b6cc-5f5a-4d0f-a09b-0663dfb9bae5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Re: [grpc-java] All RPCs failed with DEADLINE_EXCEEDED

['Kun Zhang' via grpc.io]

On Wednesday, September 27, 2017 at 4:20:03 AM UTC-7, Jorg Heymans wrote:
>
> Happy to see this being posted. We are running into this as well, it 
> happens once every couple of weeks we have no idea why. Indeed server side 
> we don't see anything in the logs it's as if nothing is going on. When it 
> happens we restart the services though, not the client application and it 
> makes the problem go away. The client does not seem to be able to recover 
> from it. It seems to be an issue only in production, presumably because the 
> client applications and services do not get restarted as much as in test ?
>

Can you clarify this part? Did or did not the client recover from it after 
you restarted the services (servers?) ? If not, what does "it makes the 
problem go away" mean? 
 

>
> We have a zookeeper based NameResolver, client deadlines are set to 10 
> seconds. Are you suggesting we should up this > 1 minute to get around any 
> resolution failures ?
>
> Thanks,
> Jorg
>
> On Tuesday, September 26, 2017 at 12:19:14 AM UTC+2, bira...@gmail.com 
> wrote:
>>
>> Language: java
>> Version: 1.5
>>
>> I ran into weird issue multiple times recently: all RPCs from one client 
>> failed with DEADLINE_EXCEEDED. From server log, it looks like these failed 
>> requests didn't arrive at server at all. Other GRPC clients worked fine 
>> during that time. The issue was fixed by restarting client application.
>> Keep-alive feature is not used in client. From my understanding, client 
>> channel should manage the underlying connection properly even keep-alive is 
>> off.
>> This issue happens occasionally and I haven't find a reliable way to 
>> reproduce.
>>
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to grpc-io@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/7b4fdef1-a1af-4492-a6bb-f692335b3e4f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Call ClientReader's Finish() function ahead of schedule will cause program block forever

[xiaonan830818]

Hi all,

I am using "A server-side streaming RPC where the client sends a request to 
the server and gets a stream to read a sequence of messages back. " mode:  

rpc transaction(request) returns (stream response) {}


My current Client cod's logic is: if find response message format error, 
doesn't receive the rest message, call the ClientReader's Finish() function:

while (reader->Read()) {
  if (response is error) {
break;
 }
}

reader->Finish();


The Server's code is simple, just for-loop write all responses:  

for (...) {

writer->Write(response); 

} 


But I find if Client doesn't read all responses, the  "reader->Finish();" 
will block forever. So my current solution is even the response has error, 
Client still need to 
read all responses.  

So my question is what is the correct method to only process half of the 
stream response? Must read all responses? 

Thanks very much in advance!

Best Reagrds
Nan Xiao

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to grpc-io@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/c7f534f0-78a6-4b0a-a52e-5eb631eb198b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.