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
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:
>
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
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
>
>
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.
>
>
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
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
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,
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
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
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
11 matches
Mail list logo
