Skip to content
This repository has been archived by the owner on Aug 31, 2023. It is now read-only.

feat: Restart failed background processor #572

Open
wants to merge 2 commits into
base: chore/use-dedicated-runtime
Choose a base branch
from

Conversation

holzeis
Copy link
Collaborator

@holzeis holzeis commented Dec 12, 2022

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.

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.
@holzeis holzeis self-assigned this Dec 12, 2022
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.
@holzeis holzeis force-pushed the feat/restart-failed-background-processor branch from 5285be0 to 0d50521 Compare December 12, 2022 15:43
@holzeis holzeis force-pushed the chore/use-dedicated-runtime branch from d895a5b to 4e54c8d Compare December 12, 2022 15:44
@luckysori
Copy link
Contributor

Not sure, why the PR includes d895a5b. Maybe you need to rebase on #571?

Copy link
Contributor

@luckysori luckysori left a 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.
Copy link
Contributor

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");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔧 It should be "unexpectedly"!

Comment on lines +530 to +536
// 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),
)));
Copy link
Contributor

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?

Copy link
Collaborator Author

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

Comment on lines -596 to +602
);
let background_processor = system.start_background_processor();
Copy link
Contributor

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.

Copy link
Collaborator Author

@holzeis holzeis Dec 15, 2022

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.

🙂

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

Successfully merging this pull request may close these issues.

2 participants