Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

A connection opened with connect_lazy does not attempt to reconnect if the server is unavailable on first request #452

Closed
K900 opened this issue Sep 8, 2020 · 3 comments · Fixed by #458
Labels
A-tonic C-bug Category: Something isn't working

Comments

@K900
Copy link
Contributor

K900 commented Sep 8, 2020

Version

tonic = 0.3.1
tonic-build = 0.3.1

Platform

Linux 4.9.104-microsoft-standard (WSL2), Linux 5.8.6-NixOS (NixOS)

Crates

Likely tonic itself.

Description

If a connection is created with connect_lazy, a first gRPC call is made, and the server is not available (e.g. not running or rejecting incoming connections), subsequent gRPC calls will not attempt to reconnect to the server, and will instead return an error.

Code and reproducible setup (Docker) here: https:/K900/tonic-issue-repro

Following up from a Discord conversation with @LucioFranco.

@LucioFranco LucioFranco added C-bug Category: Something isn't working A-tonic labels Sep 17, 2020
@LucioFranco
Copy link
Member

@alce if you have time to investigate this, that would be great, otherwise, I will try to get to it next week.

@K900 sorry for the delay!

@K900
Copy link
Contributor Author

K900 commented Sep 17, 2020

No worries!

alce added a commit to alce/tonic that referenced this issue Sep 19, 2020
Channels created with lazy connections never try to reconnect if the
first connection attempt fails. This is because `Reconnect` returns
`Poll::Ready(Err)` on poll_ready and the service is considered dead.

This change passes a flag to Reconnect to signal if the connection
is intended to be lazy, in which case reconnect returns the error on
the next call.

fixes hyperium#452
@alce
Copy link
Collaborator

alce commented Sep 19, 2020

@LucioFranco there is a possible solution in #458

@alce alce closed this as completed in #458 Sep 23, 2020
alce added a commit that referenced this issue Sep 23, 2020
* fix(transport): reconnect lazy connections after first failure

Channels created with lazy connections never try to reconnect if the
first connection attempt fails. This is because `Reconnect` returns
`Poll::Ready(Err)` on poll_ready and the service is considered dead.

This change passes a flag to Reconnect to signal if the connection
is intended to be lazy, in which case reconnect returns the error on
the next call.

fixes #452
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment