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

Smarter timeouts in offer loop #2224

Merged
merged 4 commits into from
Aug 13, 2021
Merged

Smarter timeouts in offer loop #2224

merged 4 commits into from
Aug 13, 2021

Conversation

ssalinas
Copy link
Member

stop if the total time is too long or the time processing a single request is too long

// Decisions about resources to use, specifically ports are made during the buildTask call, however
// these resources aren't subtracted from the offer until the addMatchedTask call, making this method
// not thread safe
private synchronized void acceptTask(
Copy link

Choose a reason for hiding this comment

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

Would it be possible/preferable to synchronize on the offerHolder instead of the method, to avoid blocking acceptTask calls that are using different offers?

startRequest >
mesosConfiguration.getOfferLoopRequestTimeoutMillis() &&
evaluated > 1
)
Copy link

Choose a reason for hiding this comment

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

nit - would be more readable with variables for each condition

@WH-77
Copy link

WH-77 commented Aug 12, 2021

🚢

@WH77 WH77 merged commit 825d343 into master Aug 13, 2021
@WH77 WH77 deleted the offer_timeout_loop branch August 13, 2021 15:41
@WH77 WH77 restored the offer_timeout_loop branch August 13, 2021 16:05
@ssalinas ssalinas added this to the 1.5.0 milestone May 4, 2022
@ssalinas ssalinas deleted the offer_timeout_loop branch May 4, 2022 16:40
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.

3 participants