Uh oh!
There was an error while loading. Please reload this page.
[fix](cloud-mow) Fix sending commiting rpc to FE twice problem - #41395
Conversation
doris-robot
commented
Sep 27, 2024
Thank you for your contribution to Apache Doris. Since 2024-03-18, the Document has been moved to doris-website. |
hust-hhb
commented
Sep 27, 2024
run buildall |
doris-robot
commented
Sep 27, 2024
TeamCity be ut coverage result: |
doris-robot
commented
Sep 27, 2024
TPC-H: Total hot run time: 42419 ms |
doris-robot
commented
Sep 27, 2024
TPC-DS: Total hot run time: 192131 ms |
doris-robot
commented
Sep 27, 2024
ClickBench: Total hot run time: 33.47 s |
hust-hhb
commented
Oct 10, 2024
run buildall |
doris-robot
commented
Oct 10, 2024
TeamCity be ut coverage result: |
hust-hhb
commented
Oct 11, 2024
run buildall |
doris-robot
commented
Oct 11, 2024
TeamCity be ut coverage result: |
hust-hhb
commented
Nov 7, 2024
run buildall |
doris-robot
commented
Nov 7, 2024
TPC-H: Total hot run time: 41651 ms |
doris-robot
commented
Nov 7, 2024
TPC-DS: Total hot run time: 193293 ms |
doris-robot
commented
Nov 7, 2024
ClickBench: Total hot run time: 33.44 s |
Uh oh!
There was an error while loading. Please reload this page.
PR approved by at least one committer and no changes requested. |
PR approved by anyone and no changes requested. |
hust-hhb
commented
Nov 8, 2024
run buildall |
| List<OlapTable> mowTableList = getMowTableList(tableList, tabletCommitInfos); | ||
| if (!mowTableList.isEmpty()) { | ||
| // may be this txn has been calculated by previously task but commit rpc is timeout, |
There was a problem hiding this comment.
use BE rather than "be", it's confused with the english word "be"
PR approved by at least one committer and no changes requested. |
zhannngchen
commented
Nov 13, 2024
run performance |
Here is an expample while commit rpc will send twice: 1. first commit request try to get delete bitmap lock, there is 2 lock(fe and ms), which take over rpc timeout(60s default) but not send DELETE_BITMAP_LOCK_ERR to be, and fe will continue to send calculate delete bitmap task to be 2. be calculate delete bitmap success and remove delete bitmap cache 3. because step 1 take over 60s, be will resend commit rpc to fe 4. after first commit request done, the second commit request from step 3 will do the same thing, but delete bitmap cache has been delete by first commit, so it will fail on be 5. client will see commit fail this pr check transaction status before sending delete bitmap task to be, if transaction status is committed or visible, it no need to recalculate delete bitmap again, just retrun rpc success to be.
…e#41395) Here is an expample while commit rpc will send twice: 1. first commit request try to get delete bitmap lock, there is 2 lock(fe and ms), which take over rpc timeout(60s default) but not send DELETE_BITMAP_LOCK_ERR to be, and fe will continue to send calculate delete bitmap task to be 2. be calculate delete bitmap success and remove delete bitmap cache 3. because step 1 take over 60s, be will resend commit rpc to fe 4. after first commit request done, the second commit request from step 3 will do the same thing, but delete bitmap cache has been delete by first commit, so it will fail on be 5. client will see commit fail this pr check transaction status before sending delete bitmap task to be, if transaction status is committed or visible, it no need to recalculate delete bitmap again, just retrun rpc success to be.
Here is an expample while commit rpc will send twice:
this pr check transaction status before sending delete bitmap task to be, if transaction status is committed or visible, it no need to recalculate delete bitmap again, just retrun rpc success to be.