Just wanted to clarify about the particular tag I am concerned about
(request rpc tag) - the subject of my thread. From the hello world example,
following one
service_->RequestSayHello(_, _, _, cq_, cq_, this);
I do understand that in other scenarios, it is possible for to have a false
value for
On Fri, Aug 18, 2017 at 5:11 AM, wrote:
> Having said that though, have you used nghttpx with gRPC before?
>
nghttpx is the go-to proxy with gRPC. Envoy and Istio are both built on top
of it (or at least nghttp2; it's basically the same thing).
On Friday, August
Thanks for the response.
>>We've found (the hard way) that 'ok' can be false for instance when
finishing a request whose client has already timed out.
Okay, So I need to put the logic in to detect if my server is shutting
down.
>>Other that we've observed ok to be false as described above,
We've found (the hard way) that 'ok' can be false for instance when
finishing a request whose client has already timed out.
Not sure if that's a bug or a feature.
@grpc team.
In any case it would be great to have formal specifications/doc for the
'ok' tag. It's also unclear to me
what's the
Hi,
In async model, from my experiments, when server shuts down, 'ok' will be
false. Is there any other scenario in which it can be false?
When the server is shutting down, I don't want to queue up another rpc
request. But if the 'ok' boolean can be false in some other scenario(is
there a
There are a few ways to track channel state in Python. If you only want to
block until it is connected, try
grpc.channel_ready_future(channel).result()
https://grpc.io/grpc/python/grpc.html#grpc.channel_ready_future
On Fri, Aug 18, 2017 at 7:23 AM, Julian Gold
I am working on an architecture with a single client and multiple servers.
GRPC raises an exception if the client starts without a server present, so
I tried modifying the HelloWorld sample to wait until a call succeeds:
done = False
while not done:
try:
response =
Having said that though, have you used nghttpx with gRPC before?
On Friday, August 18, 2017 at 8:10:31 AM UTC-4, matt.m...@lucidworks.com
wrote:
>
> Hi Kun. That's interesting thanks! Will definitely have a deeper look, but
> at first glance it looks like a c based lib, and we're looking to