Hi Selcuk,
Either way, you probably do not want to hard code machine IP:PORT info into
clients. In grpc we typically want to connect to a name, and let the
NameResolver turn that name into a set of HOST:PORTs for us. That way you
have the ability to have redundancy and let grpc do load balancing.
Hi,
No, our clients aren't connecting across the public internet.
So, as far as I get, we need a name resolver.
What else do we need for a successful deployment?
Thanks
--
You received this message because you are subscribed to the Google Groups
"grpc.io" group.
To unsubscribe from this
Hi Yihao
We expose the following knobs to configure channel reconnect:
INITIAL_BACKOFF, MULTIPLIER, JITTER, MAX_BACKOFF, MIN_CONNECT_TIMEOUT. Most
of those can be set via channel args (some , like jitter, have to be hard
coded, but a PR to change them to channel args should be trivia).
If that
NOTE: we are currently using gRPC v1.1.4. For various reasons, it's more
challenging for us to upgrade but please advise if this is a fixed issue in
a more recent version or any workaround that you'd suggest. Thanks for all
your work on gRPC.
I'm trying to solve an issue with a persistent gRPC
I have a problem right now. I am developing somewith for windows with GRPC
for C#. For that, I need name resolution in my GRPC application. To make it
easy, the name server is also part of one instance of the program and
implemented as GRPC service. So the application is mostly a container for
The only possible workaround right now is to make the name server a
separate application with own process id. Then, it does not use the shared
GRPC thread pool and is not getting stuck. That's ok for progressing in
development, but not a viable final solution.
--
You received this message
Hi Sree,
I want to ask another question about the exit order of a bidirectional
async stream. When I stop the grpc::Server, I am confused about the right
order.
Can I do it like this:
1. Shutdown grpc (servergrpc::Server::Shutdown)
2. Shutdown stream related CQ (cq->Shutdown())
3.
