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

Software Design: Add reconnection possibility #382

Open
haerdib opened this issue Dec 19, 2022 · 2 comments
Open

Software Design: Add reconnection possibility #382

haerdib opened this issue Dec 19, 2022 · 2 comments

Comments

@haerdib
Copy link
Contributor

haerdib commented Dec 19, 2022

Currently, only the tungstenite client offers something in that direction. Jsonrpsee sadly does offer any easy reconnection yet.
See paritytech/jsonrpsee#678 or paritytech/jsonrpsee#949

Tricky: How to avoid endless loops? A node might be very well down for good. In that case, it would be better to shut down, rather than staying alive, waiting for a dead node. And as parity wrote in paritytech/jsonrpsee#236, it should offer all the options (e.g. how long until a dead node should really be considered dead, how many retries, ..)

Also check out : paritytech/subxt#551

@haerdib haerdib added F8-newfeature Introduces a new feature Q9-needsdesign labels Dec 19, 2022
@haerdib
Copy link
Contributor Author

haerdib commented Jan 9, 2023

I've looked into that some - and I have to agree with #551 about the problem with the subscription.

Scenario:

Let's say the client has subscribed for runtime upgrades (#348), obviously in its own loop which the client created.
Now the node dies. As a result, the loop will break as well, as the subscription will return None. Or at least that's how I'd imagine it, because otherwise the client will have no knowledge of something going wrong.

If we simply reconnect the api, the loop will not be restarted, as it has been created on the client side. Resulting in a new api, that does not upgrade. No good.

Workarounds/ thoughts:

  • Do not terminate the loop for some time due to a disconnected subscription. Instead, try to resubscribe for a given amount of time or tries. Should probably be choosable from the client side. Drawback: This only works in case of the subscription is managed in the crate. In case the client as subscribed to something manually, this does not help.
  • When a subscription returns None do not directly return this to the client subscription, but instead try to resubscribe for a given amount of tries / time. (Do NOT try to reconnect in case the None is returned to an explicit unsubscribe(..)) Not sure how exactly this should be done. Maybe an additional subscription wrapper is needed and/or a lock caching the active subscriptions.

@xlc
Copy link

xlc commented Feb 2, 2023

I am working on this that implements retry for ws clients https://github.com/AcalaNetwork/subway/blob/master/src/client/mod.rs

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants