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

Conditional retry policy #1

Open
m-ronnblom opened this issue Jul 5, 2020 · 1 comment
Open

Conditional retry policy #1

m-ronnblom opened this issue Jul 5, 2020 · 1 comment
Labels
enhancement New feature or request

Comments

@m-ronnblom
Copy link
Collaborator

The current exponential back-off retry policy is designed with restarted or crashed servers or lost network connectivity in mind.

In case a protocol connection is established, but the initial protocol handshake fails (e.g. due to incompatible protocol versions), the client will retry very quickly. This retry will be successful so far another handshake will be performed, likely with the same outcome. Repeat.

In the face of errors such as above, the client should immediately go to the max configured retry timeout, to avoid excessive server load. One way to classify errors would be to retry quickly with exponential back-off only in the face XCM connectivity issues, and not in errors on the Pathfinder protocol level (e.g. wrong protocol version, not enough versions, permission issues etc).

@m-ronnblom m-ronnblom added the enhancement New feature or request label Jul 5, 2020
@m-ronnblom
Copy link
Collaborator Author

Current retry policy will reset to retry interval only if the Pathfinder protocol handshake has completed. This seems like a pretty robust solution, except for errors that repeatedly occurs past that point.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant