Thinking about this again, having TryCancel() on the call context is truly
surprising to me. It's spooky action at a distance. The call context is
used once when the stream is established, and then typically forgotten, and
the data is received by calling a method on the stream. So, why isn't
On Tuesday, October 9, 2018 at 10:03:59 PM UTC+11, Nathan Prat wrote:
>
> Thank you very much for your help
>
You're very welcome. I'm glad you got it working. :)
>
--
You received this message because you are subscribed to the Google Groups
"grpc.io" group.
To unsubscribe from this group and
I'm not sure ab is a very good benchmark tool. It used to be years ago,
but I haven't seen it used in a long time. Also, by using it you avoid the
deserialization that a real client would do.
On Tuesday, November 6, 2018 at 10:39:49 AM UTC-8, din...@wepay.com wrote:
>
> Hi,
>
> Using gRPC
Retry is already implemented (except hedging support) in v1.16.1, but there
is no other document than the spec yet, because there are some caveats for
the time being: (1) users need manage to disable census stats and tracing
when enabling retry,(2) there are some caveats for using service
This can be fixed by using "*netty-tcnative-boringssl-static*" library.
On Thursday, November 1, 2018 at 7:25:46 AM UTC-7, mrsha...@gmail.com wrote:
>
> I want to set-up SSL on my GRPC server. Here is what I'm doing:
>
> File certChain = new File("conf/server.crt");
> File privateKey = new
Hi,
Using gRPC Java RouteGuide Example available in github, I was running a
gRPC server and a REST server which contains gRPC client. Using this setup,
I tried to run AB (Apache Bench) tool to find the performance of unary and
server side streaming calls.
I noticed that the response time
