-
Notifications
You must be signed in to change notification settings - Fork 407
ChannelManager persistence #743
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
Comments
Blocking writing when we don't strictly need to seems not-ideal, especially if we can kick it off to the background, which should be roughly as fast in terms of latency between ChannelMonitor/Channel storage (during which time restarting implies channel closure). Still, not doing so means committing to a runtime, or at least spawning a single thread of our own. Given its a separate module I think I'd Lean towards a single thread, at least if we put a few other timer functions in it. |
What the severity of failing to backup a ChannelManager ? Is a direct funds loss or only a channel force-closure case ? Post #611, I think it's only the second case, if so we can allow to only schedule persistence on a given timer, not at every channel update ? At least it could be an option as a latency boost, only drop the ChannelMonitor.
You lean towards 2. IIUC ? As of today, |
Right, its only the second -
Right, I meant that we'd spawn our own thread in a
I believe its discussed in the docs (and its somewhat implied by the fact that |
The two data structures that needed to be persisted within RL are
ChannelMonitor
s and theChannelManager
.ChannelMonitor
persistence was mostly done in #681, but automatedChannelManager
persistence hasn't been touched yet.Afaik the design of
ChannelManager
persistence isn't spelled out anywhere. I'm not sure what it would ideally look like, but wanted to put out 2 design ideas for critique:We could have a similar
Persister
API, i.e.channelmanager::Persist
as the sister trait tochannelmonitor::Persist
(downside: for every e.g.update_channel
callsite, there needs to be anupdate_manager
call added too)We could just kick off
ChannelManager
persistence in the background in theFilesystemPersister
methods (i.e. asynchronously persist the CM onpersist_channel
andupdate_channel
) and document well that all implementers ofchannelmonitor::Persist
are required to do soThis is all assuming that it's best if the
ChannelManager
is re-persisted on every update to aChannelMonitor
, which I think is the case but I haven't verified this myself yet.relevant discussion: #681 (comment)
The text was updated successfully, but these errors were encountered: