Why grpc channel choose to use exponential backoff algorithm?

[yihao yang]

https://github.com/grpc/grpc/blob/master/doc/connection-backoff.md

Hi,

Can any one talk about why using exponential backoff when reconnecting? Seems I cannot costume my own reconnect algorithms outside. I can only recreate a new channel based on some stragety.

Thanks,

Yihao

[Noah Eisen]

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 does not give you enough control, then you can set wait_for_ready to false (see here), and implement custom reconnect logic there.

BEst, 

Noah

--
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/bb814336-6c46-4ab5-ac40-51688d0a2a4a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[yihao yang]

Hi, Noah

I'm using GRPC-1.0.0. I found the configurations cannot be modified or I do not know how to change those configurations.

When I issue the RPC, I will check the channel state, if I find the channel is NOT OK, I will stop sending RPC. Seems what I'm doing is already like set_wait_for_ready().

My question is:

1. Even I can use set_wait_for_ready() (not for V1.0.0 though), how can I control the retry logic by my self?

2. Seems channel will try to connect server when it is not recoverable. But can I try to actively and manually try to connect the server using Channel? That would be easy then to control the retry by myself.

Thanks,

Yihao

在 2017年7月14日星期五 UTC-7上午11:20:28，Noah Eisen写道：

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 does not give you enough control, then you can set wait_for_ready to false (see here), and implement custom reconnect logic there.

BEst, 

Noah

On Fri, Jul 14, 2017 at 11:13 AM, yihao yang <yangyi...@gmail.com> wrote:

https://github.com/grpc/grpc/blob/master/doc/connection-backoff.md

Hi,

Can any one talk about why using exponential backoff when reconnecting? Seems I cannot costume my own reconnect algorithms outside. I can only recreate a new channel based on some stragety.

Thanks,

Yihao

--
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.

[yihao yang]

Hi, Eisen:

Do we have c++ or core API to issue channel connection by the user?

I found a grpc_channel_ping. I wonder if I can use it? Can you help to describe what this API does?

Thanks,

Yihao

在 2017年7月14日星期五 UTC-7上午11:20:28，Noah Eisen写道：

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 does not give you enough control, then you can set wait_for_ready to false (see here), and implement custom reconnect logic there.

BEst, 

Noah

On Fri, Jul 14, 2017 at 11:13 AM, yihao yang <yangyi...@gmail.com> wrote:

https://github.com/grpc/grpc/blob/master/doc/connection-backoff.md

Hi,

Can any one talk about why using exponential backoff when reconnecting? Seems I cannot costume my own reconnect algorithms outside. I can only recreate a new channel based on some stragety.

Thanks,

Yihao

--
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.

[yihao yang]

If that does not give you enough control, then you can set wait_for_ready to false (see here), and implement custom reconnect logic there.

Hi, Eisen,

Not quite understand you here, I know that each RPC will try to connect the channel with wait_for_ready woth true. But what I did is I have a channel pool that I will get channels from it. So when I get the channel, it may be in the TRANS_FAILURE state. I will wait for some time (which is in our own retry logic) looking forward the state turns to CONNECTED. But actually since it has it own retry logic, sometimes I cannot succeed. That's why I want to have my control on issue the channel reconnect.

Is what I am doing not a practical way? May I return OK even when I get the TRANS_FAILURE channel?

Thanks,

Yihao

 

在 2017年7月14日星期五 UTC-7上午11:20:28，Noah Eisen写道：

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 does not give you enough control, then you can set wait_for_ready to false (see here), and implement custom reconnect logic there.

BEst, 

Noah

On Fri, Jul 14, 2017 at 11:13 AM, yihao yang <yangyi...@gmail.com> wrote:

https://github.com/grpc/grpc/blob/master/doc/connection-backoff.md

Hi,

Can any one talk about why using exponential backoff when reconnecting? Seems I cannot costume my own reconnect algorithms outside. I can only recreate a new channel based on some stragety.

Thanks,

Yihao

--
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.