-
Notifications
You must be signed in to change notification settings - Fork 411
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
Pipeline: use notify instead of polling for ExchangeSender
#9072
Conversation
/cc @gengliqi @windtalker |
I don't understand why there's always an error saying "Error: found files NOT formatted dbms/src/Flash/Mpp/tests/gtest_mpptunnel.cpp," in |
Signed-off-by: Lloyd-Pottiger <[email protected]>
Thanks a lot, @Lloyd-Pottiger . |
/hold |
/hold cancel |
if (likely(dag_context)) | ||
{ | ||
// Cancel the tunnel_set here to prevent pipeline tasks waiting in the WAIT_FOR_NOTIFY state from never being notified. | ||
if (dag_context->tunnel_set) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The tunnels will be always closed at the destruct of mpp task, is that too late so you need to close it here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, if a pipeline task is in the wait_for_notify state, and another pipeline task throws an error and cannot terminate the query, then abortMPPTunnel cannot be called, this is a deadlock.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK
abortReceivers(); | ||
abortQueryExecutor(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why abort receiver first
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is currently useless and is only used to notify exchange_receiver for the same reason as #9072 (comment).
case WaitResult::Ready: | ||
return OperatorStatus::NEED_INPUT; | ||
case WaitResult::WaitForPolling: | ||
return OperatorStatus::WAITING; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if return WAITING
, it will still use wait reactor thread to check if it is ready, is my understand right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, you are right.
Here only wait for tunnel ready will return WaitForPolling
.
if (likely(dag_context)) | ||
{ | ||
// Cancel the tunnel_set here to prevent pipeline tasks waiting in the WAIT_FOR_NOTIFY state from never being notified. | ||
if (dag_context->tunnel_set) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
@@ -139,6 +139,9 @@ class GRPCSendQueue | |||
|
|||
bool isWritable() const { return send_queue.isWritable(); } | |||
|
|||
void registerPipeReadTask(TaskPtr && task) { send_queue.registerPipeReadTask(std::move(task)); } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems these registerPipeReadTask
s are not used in this PR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, they are used in the exchange receiver PR, but not in this PR.
https://github.com/pingcap/tiflash/pull/9073/files
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: gengliqi, windtalker The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
[LGTM Timeline notifier]Timeline:
|
/merge |
@SeaRise: Your PR was out of date, I have automatically updated it for you. At the same time I will also trigger all tests for you: /run-all-tests
If the CI test fails, you just re-trigger the test that failed and the bot will merge the PR for you after the CI passes. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the ti-community-infra/tichi repository. |
close #9413 Signed-off-by: xufei <[email protected]>
What problem does this PR solve?
Issue Number: ref #8869
Problem Summary:
What is changed and how it works?
use
waitForWritable()
to replaceisWritable()
Check List
Tests
Tested tpch50, no performance regression
Side effects
Documentation
Release note