grpc Dial behavior

[amit.c...@gmail.com]

Hi,

        I have a question regarding the grpc Dial behavior. I have a server, which as part of the incoming request needs to talk to another endpoint using grpc. Currently, on the server spawn, it does grpc.Dial to the other endpoint. and when the request comes, it does a grpc on this established connection. Two questions:

1. Is the connection via grpc.Dial persistent?

2. On the connection loss to the other endpoint, my grpc requests are failing

err rpc error: code = Unavailable desc = all SubConns are in TransientFailure

Do i need to dial out per request, that sounds expensive as the connection establishment can take time. I was under the impression that Dial will indefinitely try to establish the connection. Do i need to explicitly turn on keepAlive to make that happen?

3. Also, if i want to limit how long the grpc request should take, one way i know of is via the golang context. I was reading somewhere that the grpc call itself, you can pass timeout. Which method is preferred?

Thanks

Amit

[Josh Humphries]

It is a persistent connection. But if you only have one backend (or, more importantly, one hostname, such as behind a hardware load balancer and/or proxy), the client does not create redundant connections. So there is some downtime while it re-creates a socket connection after it gets disconnected.

This downtime is usually short, so you can usually get by using a grpc.FailFast(false) call option. The default is fail-fast, which means the RPC fails if a connection is not available. But with that setting false, it will wait for the connection to become available. You should definitely use a timeout when setting fail-fast to false, so it doesn't wait too long for a connection to recover.

You set a timeout via the context, as you would for other I/O that should be deadline-driven or cancellable.

You can use an interceptor to set the timeout for all calls that do not already have a timeout (e.g. apply a default, so that you don't have to specify explicit timeouts everywhere in code). The interceptor can also add the fail-fast call option to every call, so you don't have to do that explicitly everywhere, too.

----
Josh Humphries
jh...@bluegosling.com

--
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+unsubscribe@googlegroups.com.
To post to this group, send email to grp...@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/c0000499-7a3c-4548-a5ca-028c03d7cc32%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[amit.c...@gmail.com]

Thanks Josh. I ended up using the go-grpc-middleware for the interceptor.

Looks like Dial without the WithBlock option indefinitely tries connecting (in the background) to the server?? 

During the rpc call, if the connection is not established, the retry logic in the middleware, tries connecting again.

Is that a fair understanding of how it works?

Thanks

Amit

On Thursday, February 22, 2018 at 11:22:56 AM UTC-8, Josh Humphries wrote:

It is a persistent connection. But if you only have one backend (or, more importantly, one hostname, such as behind a hardware load balancer and/or proxy), the client does not create redundant connections. So there is some downtime while it re-creates a socket connection after it gets disconnected.

This downtime is usually short, so you can usually get by using a grpc.FailFast(false) call option. The default is fail-fast, which means the RPC fails if a connection is not available. But with that setting false, it will wait for the connection to become available. You should definitely use a timeout when setting fail-fast to false, so it doesn't wait too long for a connection to recover.

You set a timeout via the context, as you would for other I/O that should be deadline-driven or cancellable.

You can use an interceptor to set the timeout for all calls that do not already have a timeout (e.g. apply a default, so that you don't have to specify explicit timeouts everywhere in code). The interceptor can also add the fail-fast call option to every call, so you don't have to do that explicitly everywhere, too.

----
Josh Humphries
jh...@bluegosling.com

On Thu, Feb 22, 2018 at 1:57 PM, <amit.c...@gmail.com> wrote:

Hi,

        I have a question regarding the grpc Dial behavior. I have a server, which as part of the incoming request needs to talk to another endpoint using grpc. Currently, on the server spawn, it does grpc.Dial to the other endpoint. and when the request comes, it does a grpc on this established connection. Two questions:

1. Is the connection via grpc.Dial persistent?

2. On the connection loss to the other endpoint, my grpc requests are failing

err rpc error: code = Unavailable desc = all SubConns are in TransientFailure

Do i need to dial out per request, that sounds expensive as the connection establishment can take time. I was under the impression that Dial will indefinitely try to establish the connection. Do i need to explicitly turn on keepAlive to make that happen?

3. Also, if i want to limit how long the grpc request should take, one way i know of is via the golang context. I was reading somewhere that the grpc call itself, you can pass timeout. Which method is preferred?

Thanks

Amit

--
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+u...@googlegroups.com.