-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
wtclient: Tower Client Multiplexer #7702
wtclient: Tower Client Multiplexer #7702
Conversation
7fbbf06
to
0c86191
Compare
ea88b2d
to
986edc2
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Concept ACK
986edc2
to
f93b193
Compare
24cc3f8
to
1ee86b4
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great work, as always super clean commit structure and easy to follow story telling 💯
And I love the optimizations and cleanup that went into the code as well.
Do we want to update this to 0-18-staging
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @guggero !
Do we want to update this to 0-18-staging?
Since that is about to be merged into master - I'll wait for that :)
93d06ad
to
2b15920
Compare
2b15920
to
61b04dc
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome, this is very very close! Just two remaining questions.
watchtower/wtclient/manager.go
Outdated
log.Errorf("no client currently " + | ||
"active for the session type") | ||
|
||
return |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What happens when we return here and below?
Won't the manager basically be in a state where it doesn't continue to work and there might be a memory buildup?
Not sure if it would make sense to either continue
here or log a critical error to force a shutdown? Depending on the severity of the error?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah good catch - I think it makes sense to continue here since if anything fails, it is fine for us to just drop it since it will retry on start up since the session's will still be around & marked as closable
61b04dc
to
51abaad
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Really nice PR, great to follow along with this commit structure 🏅! Will also do a test run as the next step, but overall the PR looks good
51abaad
to
ae9ab62
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the review @bitromortac !
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, tACK 🎉
Introduce a wtclient `Manager` which handles tower clients. It indexes clients by the policy used. The policy field is thus removed from the `Config` struct which configures the Manager and is instead added to a new `towerClientCfg` which configures a specific client managed by the manager. For now, only the `NewClient` method is added to the Manager. It can be used to construct a new `TowerClient`. The Manager currently does notthing with the clients added to it.
In this commit, the `Stop` and `Start` methods are removed from the `Client` interface and instead added to the new `Manager`. Callers now only need to call the Manager to start or stop the clients instead of needing to call stop/start on each individual client.
In this commit we move the AddTower method from the Client interface to the TowerClientManager interface. The wtclientrpc is updated to call the `AddTower` method of the Manager instead of calling the `AddTower` method of each individual client. The TowerClient now is also only concerned with adding a new tower (or new tower address) to its in-memory state; the tower Manager will handle adding the tower to the DB.
Simiarly to the previous commit, this commit moves the RemoveTower method from the Client to the TowerClientManager interface. The manager handles any DB related handling. The manager will first attempt to remove the tower from the in-memory state of each client and then will attempt to remove the tower from the DB. If the removal from the DB fails, the manager will re-add the tower to the in-memory state of each client.
This commit removes the mutex from ClientStats and instead puts that in clientStats which wraps ClientStats with a mutex. This is so that the tower client interface can return a ClientStats struct without worrying about copying a mutex.
Move the `Stats` method from the `Client` to the `Manager` interface.
Move the `RegisteredTowers` method from the `Client` to the `Manager` interface.
working on the rebase 👍 |
This commit moves over the last two methods, `RegisterChannel` and `BackupState` from the `Client` to the `Manager` interface. With this change, we no longer need to pass around the individual clients around and now only need to pass the manager around. To do this change, all the goroutines that handle channel closes, closable sessions needed to be moved to the Manager and so a large part of this commit is just moving this code from the TowerClient to the Manager.
Rename and unexport the `TowerClient` struct to `client` and rename the `TowerClientManager` interface to `ClientManager`.
ae9ab62
to
59ebe02
Compare
@guggero: review reminder |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very nice, LGTM 🎉
Currently in LND, two separate
TowerClients
get created, one for legacychannels and one for anchor channels. When taproot channels come along, we
would have to have yet another one of these clients with more switch statements.
So with this PR, a Client Multiplexer is added which manages the tower clients so
that only one object needs to be passed around and called from other parts of the
code base. The multiplexer will handle the separate clients.
Fixes #7540
This is a pre-requisite for #7733