Skip to content

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.

4 participants