-
Notifications
You must be signed in to change notification settings - Fork 3
feat: Restart failed background processor #572
base: chore/use-dedicated-runtime
Are you sure you want to change the base?
feat: Restart failed background processor #572
Conversation
Annotating the function with `#[tokio::main]` killed the runtime after the function completes. Thus we had to block the run function indefinitely for the long living threads to keep going. This change introduces a runtime managed outside of the function scope and thus allows the `run` function to return bringing the following advantages. - We don't block a whole frb worker thread just to run the lightning node, sync tasks, background processor, etc. - We are using a multi threaded runtime instead of the current thread - allowing to actually join the background processor without blocking all other tasks. - making better use of multiple cpu cores. - We are not creating a new runtime on every async bridge call.
Adds and handling in case the background processor stops, by simply trying to start the background processor again. Some more refactoring could be probably done there, but I tried to keep the changes to a minimum.
5285be0
to
0d50521
Compare
d895a5b
to
4e54c8d
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.
LGTM! (In only reviewed 0d50521).
let mut background_processor = background_processor; | ||
loop { | ||
// background processor joins on a sync thread, meaning that join here will block a | ||
// full thread, which is dis-encouraged to do in async code. |
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.
🔧 It should be "discouraged"!
// background processor joins on a sync thread, meaning that join here will block a | ||
// full thread, which is dis-encouraged to do in async code. | ||
if let Err(err) = background_processor.join() { | ||
tracing::warn!(?err, "Background processor stopped unexpected"); |
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.
🔧 It should be "unexpectedly"!
// Step 17: Initialize routing ProbabilisticScorer | ||
let scorer_path = format!("{ldk_data_dir}/scorer"); | ||
let scorer = Arc::new(Mutex::new(disk::read_scorer( | ||
Path::new(&scorer_path), | ||
Arc::clone(&network_graph), | ||
Arc::clone(&logger), | ||
))); |
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.
❓ Why did we have to move this?
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.
to be able to start the background processor from the properties of the lightning system
); | ||
let background_processor = system.start_background_processor(); |
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.
🔧 I'm not a huge fan of calling this here (inside of run_ldk
) and also on the outside when restarting the background processor.
Actually, this function appears to be doing only 2 things:
- Setting the
INVOICE_PAYER
static variable, something that should only happen once during the lifetime of the app AFAIK. - Starting the background processor via the
LightningSystem
.
As such, I think we should get rid of the run_ldk
function and just do those two things separately when necessary.
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.
agreed, but
Some more refactoring could be probably done there, but I tried to keep the changes to a minimum.
🙂
Adds and handling in case the background processor stops, by simply trying to start the background processor again.
Some more refactoring could be probably done there, but I tried to keep the changes to a minimum.