Re: [grpc-io] Re: C++ API, unidirectional streaming: How to tell if receiver closed the connection?

[Arthur Wang]

I  accidentally worked around the problem by define a bidirectional RPC and
make client periodically sending an acknowledge message among the normal
stream messages to the server , if the server can't give a positive
response to that ack, consider it as shutdown.

On Sun, Nov 25, 2018 at 7:01 PM  wrote:

> This is not a solution for me as the channel is used for others RPC calls,
> having a server cancelling a client stream should not change the channel
> status.
>
> On Friday, November 23, 2018 at 7:07:23 PM UTC+1, men...@gmail.com wrote:
>>
>> I have the same issue look at this:
>> https://github.com/grpc/grpc/issues/17236
>>
>> I have kinda solved (I need to do some further tests) observing the
>> underlying channel status.
>>
>> --
> 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/98d282c1-8511-4499-ba01-f1797e1b99e6%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/CAKymdqNi%3DpJ8MD9bPHSyBaH%2Bzh42spas99dE-xDECkHFBCVCtg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Re: C++ API, unidirectional streaming: How to tell if receiver closed the connection?

[pleuba]

This is not a solution for me as the channel is used for others RPC calls, 
having a server cancelling a client stream should not change the channel 
status.

On Friday, November 23, 2018 at 7:07:23 PM UTC+1, men...@gmail.com wrote:
>
> I have the same issue look at this:  
> https://github.com/grpc/grpc/issues/17236
>
> I have kinda solved (I need to do some further tests) observing the 
> underlying channel status.
>
>

-- 
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/98d282c1-8511-4499-ba01-f1797e1b99e6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Re: C++ API, unidirectional streaming: How to tell if receiver closed the connection?

[mendola]

This approach doesn't decrease the client->server throughput ?

On Wednesday, 21 November 2018 17:24:21 UTC+1, m...@stackrox.com wrote:
>
> I did, sort of. I made the streaming bidirectional (basically rpc 
> MyMethod (stream ClientMsg) return (stream google.protobuf.Empty) ), and 
> attempting client-side recv's now gives an option to reliably check for 
> error. I also wrapped the whole grpc interface into a select-style 
> interface (as I didn't want to use threads and thought the async interface 
> is overly complicated, especially considering I didn't *really* need that 
> full-duplex functionality). I can share it here if you're interested (need 
> to check w/ employer but shouldn't be an issue).
>
> Hope that helps,
> Malte
>
> On Wednesday, November 21, 2018 at 8:17:04 AM UTC-8, ple...@swissonline.ch 
> wrote:
>>
>> Hi,
>>
>> I face the same problem, did you find a solution ?
>>
>

-- 
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/4483c45f-68b4-4eae-aeed-6bcd2ab7f3f4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [grpc-io] Re: C++ API, unidirectional streaming: How to tell if receiver closed the connection?

[Malte Isberner]

In my case the transport was perfectly fine. The was another stream over
the same transport channel which worked as expected. So, I could get
nothing from the transport channel status.

On Fri, Nov 23, 2018, 10:07  I have the same issue look at this:
> https://github.com/grpc/grpc/issues/17236
>
> I have kinda solved (I need to do some further tests) observing the
> underlying channel status.
>
> On Friday, 21 September 2018 09:24:44 UTC+2, Malte Isberner wrote:
>>
>> One detail I forgot in my example, which is now happily running for >10m
>> without reporting an error on Write(): The messages I send are indeed very
>> small, but I'm passing `grpc::WriteOptions().set_write_through()` to every
>> Write call, so buffering should not be the issue here (and if I understand
>> things correctly, it shouldn't be even without that option).
>>
>>
>> On Friday, September 21, 2018 at 12:17:34 AM UTC-7, malte.i...@gmail.com
>> wrote:
>>>
>>> Ok, it seems like the situation is even worse, and this is really
>>> frustrating.
>>>
>>> Using a Go GRPC server (didn't test anything else), I cannot even get
>>> `Write()` to fail even when the remote server does not implement the method
>>> I'm calling! I'm sending a message every 5 seconds to a GRPC server that
>>> doesn't implement the method/service, and I keep getting `true` return
>>> values (code is running for >5m now). Now, I can call `Finish` at any time
>>> and will then in fact get the "unknown service xyz" in the status response,
>>> but for that I'd have to close the stream - doesn't work with my use case.
>>>
>>> I somehow can't believe that this is really the state of affairs with
>>> the GRPC C++ API, but I've looked through most of the API and don't see a
>>> solution. I apologize if that sounds harsh, but if it is impossible to make
>>> a client-side streaming RPC call without knowing whether all the data gets
>>> effectively sent to /dev/null before closing this stream (regardless of
>>> session length), it seems that client-side streaming is effectively
>>> unusable from C++..? (This very use case works absolutely fine in Golang)
>>>
>>> On Wednesday, September 19, 2018 at 4:55:40 PM UTC-7, m...@stackrox.com
>>> wrote:

 Hi,

 I'm having trouble using the GRPC C++ API for a unidirectional stream
 RPC (client streaming, client is written in C++, server in Go).

 Unless I'm missing something, it seems that the only way to find out if
 the remote (receiving) end of the stream aborted the GRPC call is by
 actually calling Write(). For streaming connections that send data only
 infrequently (but which need to be streaming nonetheless, due to
 statefulness of a single "call" and ordering guarantees), this seems very
 unsatisfying. Even when using the stream to send keep-alives at regular
 intervals (which I do not believe should be done at the application level),
 the fact that a call to `Write

>>> --
> 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/Xo_kqZwuDoA/unsubscribe.
> To unsubscribe from this group and all its topics, 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/30122907-c20e-4454-9546-6cb03ea1f884%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/CADUCzEtj7PjTSsT6jF%3D%3D-TjaV4ZeKnjj%3DtJVPXpn9qUSjN4OWA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Re: C++ API, unidirectional streaming: How to tell if receiver closed the connection?

[mendola]

Also I have to say I'm puzzled as well about the client streaming use 
case:  https://groups.google.com/forum/#!topic/grpc-io/7alTzx7YRKE


On Friday, 21 September 2018 09:17:34 UTC+2, Malte Isberner wrote:
>
> Ok, it seems like the situation is even worse, and this is really 
> frustrating.
>
> Using a Go GRPC server (didn't test anything else), I cannot even get 
> `Write()` to fail even when the remote server does not implement the method 
> I'm calling! I'm sending a message every 5 seconds to a GRPC server that 
> doesn't implement the method/service, and I keep getting `true` return 
> values (code is running for >5m now). Now, I can call `Finish` at any time 
> and will then in fact get the "unknown service xyz" in the status response, 
> but for that I'd have to close the stream - doesn't work with my use case.
>
> I somehow can't believe that this is really the state of affairs with the 
> GRPC C++ API, but I've looked through most of the API and don't see a 
> solution. I apologize if that sounds harsh, but if it is impossible to make 
> a client-side streaming RPC call without knowing whether all the data gets 
> effectively sent to /dev/null before closing this stream (regardless of 
> session length), it seems that client-side streaming is effectively 
> unusable from C++..? (This very use case works absolutely fine in Golang)
>
> On Wednesday, September 19, 2018 at 4:55:40 PM UTC-7, m...@stackrox.com 
> wrote:
>>
>> Hi,
>>
>> I'm having trouble using the GRPC C++ API for a unidirectional stream RPC 
>> (client streaming, client is written in C++, server in Go).
>>
>> Unless I'm missing something, it seems that the only way to find out if 
>> the remote (receiving) end of the stream aborted the GRPC call is by 
>> actually calling Write(). For streaming connections that send data only 
>> infrequently (but which need to be streaming nonetheless, due to 
>> statefulness of a single "call" and ordering guarantees), this seems very 
>> unsatisfying. Even when using the stream to send keep-alives at regular 
>> intervals (which I do not believe should be done at the application level), 
>> the fact that a call to `Write
>>
>

-- 
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/1b76969b-3240-4d5b-9552-0a6b24644033%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Re: C++ API, unidirectional streaming: How to tell if receiver closed the connection?

[mendola]

I have the same issue look at this:  
https://github.com/grpc/grpc/issues/17236

I have kinda solved (I need to do some further tests) observing the 
underlying channel status.

On Friday, 21 September 2018 09:24:44 UTC+2, Malte Isberner wrote:
>
> One detail I forgot in my example, which is now happily running for >10m 
> without reporting an error on Write(): The messages I send are indeed very 
> small, but I'm passing `grpc::WriteOptions().set_write_through()` to every 
> Write call, so buffering should not be the issue here (and if I understand 
> things correctly, it shouldn't be even without that option).
>
>
> On Friday, September 21, 2018 at 12:17:34 AM UTC-7, malte.i...@gmail.com 
> wrote:
>>
>> Ok, it seems like the situation is even worse, and this is really 
>> frustrating.
>>
>> Using a Go GRPC server (didn't test anything else), I cannot even get 
>> `Write()` to fail even when the remote server does not implement the method 
>> I'm calling! I'm sending a message every 5 seconds to a GRPC server that 
>> doesn't implement the method/service, and I keep getting `true` return 
>> values (code is running for >5m now). Now, I can call `Finish` at any time 
>> and will then in fact get the "unknown service xyz" in the status response, 
>> but for that I'd have to close the stream - doesn't work with my use case.
>>
>> I somehow can't believe that this is really the state of affairs with the 
>> GRPC C++ API, but I've looked through most of the API and don't see a 
>> solution. I apologize if that sounds harsh, but if it is impossible to make 
>> a client-side streaming RPC call without knowing whether all the data gets 
>> effectively sent to /dev/null before closing this stream (regardless of 
>> session length), it seems that client-side streaming is effectively 
>> unusable from C++..? (This very use case works absolutely fine in Golang)
>>
>> On Wednesday, September 19, 2018 at 4:55:40 PM UTC-7, m...@stackrox.com 
>> wrote:
>>>
>>> Hi,
>>>
>>> I'm having trouble using the GRPC C++ API for a unidirectional stream 
>>> RPC (client streaming, client is written in C++, server in Go).
>>>
>>> Unless I'm missing something, it seems that the only way to find out if 
>>> the remote (receiving) end of the stream aborted the GRPC call is by 
>>> actually calling Write(). For streaming connections that send data only 
>>> infrequently (but which need to be streaming nonetheless, due to 
>>> statefulness of a single "call" and ordering guarantees), this seems very 
>>> unsatisfying. Even when using the stream to send keep-alives at regular 
>>> intervals (which I do not believe should be done at the application level), 
>>> the fact that a call to `Write
>>>
>>

-- 
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/30122907-c20e-4454-9546-6cb03ea1f884%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Re: C++ API, unidirectional streaming: How to tell if receiver closed the connection?

[mi]

I did, sort of. I made the streaming bidirectional (basically rpc MyMethod 
(stream ClientMsg) return (stream google.protobuf.Empty) ), and attempting 
client-side recv's now gives an option to reliably check for error. I also 
wrapped the whole grpc interface into a select-style interface (as I didn't 
want to use threads and thought the async interface is overly complicated, 
especially considering I didn't *really* need that full-duplex 
functionality). I can share it here if you're interested (need to check w/ 
employer but shouldn't be an issue).

Hope that helps,
Malte

On Wednesday, November 21, 2018 at 8:17:04 AM UTC-8, ple...@swissonline.ch 
wrote:
>
> Hi,
>
> I face the same problem, did you find a solution ?
>

-- 
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/07218d77-b58b-42ff-a4a6-1688eb9b3639%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Re: C++ API, unidirectional streaming: How to tell if receiver closed the connection?

[pleuba]

Hi,

I face the same problem, did you find a solution ?

-- 
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/6e325872-5b81-44f0-8692-243cb2e18a02%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Re: C++ API, unidirectional streaming: How to tell if receiver closed the connection?

[malte . isberner]

One detail I forgot in my example, which is now happily running for >10m 
without reporting an error on Write(): The messages I send are indeed very 
small, but I'm passing `grpc::WriteOptions().set_write_through()` to every 
Write call, so buffering should not be the issue here (and if I understand 
things correctly, it shouldn't be even without that option).


On Friday, September 21, 2018 at 12:17:34 AM UTC-7, malte.i...@gmail.com 
wrote:
>
> Ok, it seems like the situation is even worse, and this is really 
> frustrating.
>
> Using a Go GRPC server (didn't test anything else), I cannot even get 
> `Write()` to fail even when the remote server does not implement the method 
> I'm calling! I'm sending a message every 5 seconds to a GRPC server that 
> doesn't implement the method/service, and I keep getting `true` return 
> values (code is running for >5m now). Now, I can call `Finish` at any time 
> and will then in fact get the "unknown service xyz" in the status response, 
> but for that I'd have to close the stream - doesn't work with my use case.
>
> I somehow can't believe that this is really the state of affairs with the 
> GRPC C++ API, but I've looked through most of the API and don't see a 
> solution. I apologize if that sounds harsh, but if it is impossible to make 
> a client-side streaming RPC call without knowing whether all the data gets 
> effectively sent to /dev/null before closing this stream (regardless of 
> session length), it seems that client-side streaming is effectively 
> unusable from C++..? (This very use case works absolutely fine in Golang)
>
> On Wednesday, September 19, 2018 at 4:55:40 PM UTC-7, m...@stackrox.com 
> wrote:
>>
>> Hi,
>>
>> I'm having trouble using the GRPC C++ API for a unidirectional stream RPC 
>> (client streaming, client is written in C++, server in Go).
>>
>> Unless I'm missing something, it seems that the only way to find out if 
>> the remote (receiving) end of the stream aborted the GRPC call is by 
>> actually calling Write(). For streaming connections that send data only 
>> infrequently (but which need to be streaming nonetheless, due to 
>> statefulness of a single "call" and ordering guarantees), this seems very 
>> unsatisfying. Even when using the stream to send keep-alives at regular 
>> intervals (which I do not believe should be done at the application level), 
>> the fact that a call to `Write
>>
>

-- 
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/c8560fe6-2305-4675-a98b-beb8ec794c68%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Re: C++ API, unidirectional streaming: How to tell if receiver closed the connection?

[malte . isberner]

Ok, it seems like the situation is even worse, and this is really 
frustrating.

Using a Go GRPC server (didn't test anything else), I cannot even get 
`Write()` to fail even when the remote server does not implement the method 
I'm calling! I'm sending a message every 5 seconds to a GRPC server that 
doesn't implement the method/service, and I keep getting `true` return 
values (code is running for >5m now). Now, I can call `Finish` at any time 
and will then in fact get the "unknown service xyz" in the status response, 
but for that I'd have to close the stream - doesn't work with my use case.

I somehow can't believe that this is really the state of affairs with the 
GRPC C++ API, but I've looked through most of the API and don't see a 
solution. I apologize if that sounds harsh, but if it is impossible to make 
a client-side streaming RPC call without knowing whether all the data gets 
effectively sent to /dev/null before closing this stream (regardless of 
session length), it seems that client-side streaming is effectively 
unusable from C++..? (This very use case works absolutely fine in Golang)

On Wednesday, September 19, 2018 at 4:55:40 PM UTC-7, m...@stackrox.com 
wrote:
>
> Hi,
>
> I'm having trouble using the GRPC C++ API for a unidirectional stream RPC 
> (client streaming, client is written in C++, server in Go).
>
> Unless I'm missing something, it seems that the only way to find out if 
> the remote (receiving) end of the stream aborted the GRPC call is by 
> actually calling Write(). For streaming connections that send data only 
> infrequently (but which need to be streaming nonetheless, due to 
> statefulness of a single "call" and ordering guarantees), this seems very 
> unsatisfying. Even when using the stream to send keep-alives at regular 
> intervals (which I do not believe should be done at the application level), 
> the fact that a call to `Write
>

-- 
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/5f4890eb-d40f-469f-853a-aac28cda8a8e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Re: C++ API, unidirectional streaming: How to tell if receiver closed the connection?

[mi]

Whoops, hit reply to early.

Even when using the stream to send keep-alives at regular intervals (which 
I do not believe should be done at the application level), the fact that a 
call to `Write` might return true just after writing to the buffer might 
make even this approach unreliable.

Any help would be very much appreciated.

Note: I'm using the sync API, but I didn't find anything in the async API 
either.

On Wednesday, September 19, 2018 at 4:55:40 PM UTC-7, m...@stackrox.com 
wrote:
>
> Hi,
>
> I'm having trouble using the GRPC C++ API for a unidirectional stream RPC 
> (client streaming, client is written in C++, server in Go).
>
> Unless I'm missing something, it seems that the only way to find out if 
> the remote (receiving) end of the stream aborted the GRPC call is by 
> actually calling Write(). For streaming connections that send data only 
> infrequently (but which need to be streaming nonetheless, due to 
> statefulness of a single "call" and ordering guarantees), this seems very 
> unsatisfying. Even when using the stream to send keep-alives at regular 
> intervals (which I do not believe should be done at the application level), 
> the fact that a call to `Write
>

-- 
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/688fc590-c8a4-4a39-9704-28b5e9b9325d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.