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

Make call SchedulerServer::new once in ballista-scheduler process #1537

Merged
merged 3 commits into from
Jan 13, 2022

Conversation

Ted-Jiang
Copy link
Member

Which issue does this PR close?

Closes #1531 .

avoid tokio::spawn(async move { state_clone.synchronize_job_status_loop(). multi-times

@Ted-Jiang
Copy link
Member Author

@houqp @alamb Plz have a review.

@houqp houqp requested review from andygrove and alamb January 11, 2022 03:40
@@ -62,14 +63,18 @@ async fn start_server(
"Ballista v{} Scheduler listening on {:?}",
BALLISTA_VERSION, addr
);
//there should be only one SchedulerServer in process
Copy link
Contributor

Choose a reason for hiding this comment

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

I don't understand how this code ensures just one SchedulerServer exists per process.

It seems to me what this code does is create a new SchedulerServer on a port that the operating system picks.

Copy link
Contributor

Choose a reason for hiding this comment

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

Perhaps using something like lazy_static (https://docs.rs/lazy_static/1.4.0/lazy_static/, already a dependency) might be worth looking into

Copy link
Member Author

Choose a reason for hiding this comment

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

Thanks, sorry for my wrong annotation. it should be only call SchedulerServer::new() once in process ,
is this right ?

Copy link
Member Author

Choose a reason for hiding this comment

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

its ok to clone() SchedulerServer in multi-thread without call tokio::spawn(async move { state_clone.synchronize_job_status_loop().await });

Copy link
Member

Choose a reason for hiding this comment

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

SchedulerServer::new creates the scheduler loop that runs in the background, that's the thing that's causing the issue.

Copy link
Member Author

Choose a reason for hiding this comment

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

@alamb Could you review it again, Thanks!

Copy link
Contributor

Choose a reason for hiding this comment

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

Sorry -- I don't really know what this code is doing, so I just had an uninformed question; Sorry if this delayed merging unnecessarily.

@Ted-Jiang Ted-Jiang requested a review from alamb January 12, 2022 13:53
@alamb
Copy link
Contributor

alamb commented Jan 13, 2022

If it fixes your issues @Ted-Jiang then it sounds good to me 👍

@alamb alamb merged commit cf76969 into apache:master Jan 13, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Ballista scheduler dead loop in loadtest
3 participants