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

Allow some tasks waiting for node per stage before blocking scheduling #11740

Merged
merged 1 commit into from
Apr 9, 2022

Conversation

losipiuk
Copy link
Member

@losipiuk losipiuk commented Mar 31, 2022

Description

Allow some tasks waiting for node per stage before blocking scheduling

Is this change a fix, improvement, new feature, refactoring, or other?

improvement

Is this a change to the core query engine, a connector, client library, or the SPI interfaces? (be specific)

core query engine

Related issues, pull requests, and links

Fixes #10808

Documentation

( ) No documentation is needed.
(x) Sufficient documentation is included in this PR.
( ) Documentation PR is available with #prnumber.
( ) Documentation issue #issuenumber is filed, and can be handled later.

Release notes

(x) No release notes entries required.
( ) Release notes entries required with the following suggested text:

@cla-bot cla-bot bot added the cla-signed label Mar 31, 2022
@losipiuk losipiuk force-pushed the lo/stage-scheduler-non-block branch from b84e9f8 to a165d03 Compare April 1, 2022 14:30
@losipiuk losipiuk changed the title WIP: allow multiple pending nodes per stage Allow some tasks waiting for node per stage before blocking scheduling Apr 1, 2022
@losipiuk losipiuk force-pushed the lo/stage-scheduler-non-block branch from a165d03 to 48659f5 Compare April 1, 2022 14:36
@losipiuk losipiuk marked this pull request as ready for review April 1, 2022 14:36
@losipiuk losipiuk requested review from linzebing and arhimondr April 1, 2022 14:36
@github-actions github-actions bot added the docs label Apr 1, 2022
@losipiuk losipiuk force-pushed the lo/stage-scheduler-non-block branch from 48659f5 to 18741f2 Compare April 4, 2022 13:06
Copy link
Contributor

@arhimondr arhimondr left a comment

Choose a reason for hiding this comment

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

LGTM % comment

@@ -153,6 +153,7 @@
public static final String QUERY_RETRY_ATTEMPTS = "query_retry_attempts";
public static final String TASK_RETRY_ATTEMPTS_OVERALL = "task_retry_attempts_overall";
public static final String TASK_RETRY_ATTEMPTS_PER_TASK = "task_retry_attempts_per_task";
public static final String MAX_TASKS_WAITING_FOR_NODE_PER_STAGE = "max_tasks_waiting_for_node_per_stage";
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: maybe prefix it with FAULT_TOLERANT_EXECUTIO_ (similar to other Tardigrade related configs)?

Copy link
Member Author

Choose a reason for hiding this comment

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

it gets very long then :) Also session properties above are not prefixed - and also tardigrade specific .

Copy link
Contributor

Choose a reason for hiding this comment

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

That's a good point. It looks like we are somehow inconsistent. Some of the properties are prefixed when some of them are not. I wonder what should be the guideline. What do you think?

Copy link
Member Author

Choose a reason for hiding this comment

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

If property is only applicable to fault-tolerant execution I am option for prefixing. THough it would be nice to have something shorter than fault_tolerant_execution_ :) No idea for alternative though.

On the other hand at some point we may migrate to just having a single execution mode - then prefixing is not needed. Then dropping prefix already is more future proof :)

@losipiuk
Copy link
Member Author

losipiuk commented Apr 8, 2022

CI: #11876

@losipiuk losipiuk force-pushed the lo/stage-scheduler-non-block branch from 18741f2 to ab53e91 Compare April 8, 2022 16:46
@losipiuk losipiuk force-pushed the lo/stage-scheduler-non-block branch from ab53e91 to 9bbf603 Compare April 9, 2022 07:42
@losipiuk
Copy link
Member Author

losipiuk commented Apr 9, 2022

CI: #11893

@losipiuk losipiuk merged commit 6a2e3bd into trinodb:master Apr 9, 2022
@github-actions github-actions bot added this to the 377 milestone Apr 9, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging this pull request may close these issues.

Do not block FaultTolerantStageScheduler loop if node cannot be acquire for single task
3 participants