Skip to content

Conversation

@zh0122
Copy link
Contributor

@zh0122 zh0122 commented Jun 4, 2021

Proposed changes

Although the table lock can control the simultaneous modification of the table by different threads.
But it cannot control the drop operation of the table by other threads.
For example, when drop table and table update occur at the same time.

get table object by thread 1
drop table by thread 2 with table lock
update table object by thread 1
The above process is possible.
At this time, step 3 actually operates a table that no longer exists, which will eventually cause NullPointerException.

In fact, the modified table log after the drop table can be ignored. The reason is that it is meaningless to modify information on a table that no longer exists.

Fixed #5687

Types of changes

What types of changes does your code introduce to Doris?
Put an x in the boxes that apply

  • Bugfix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • Documentation Update (if none of the other choices apply)
  • Code refactor (Modify the code structure, format the code, etc...)

Checklist

Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code.

  • I have created an issue on (Fix Replay update replica failed when table has been dropped #5687 ) and described the bug/feature there in detail
  • Compiling and unit tests pass locally with my changes
  • I have added tests that prove my fix is effective or that my feature works
  • If these changes need document changes, I have updated the document
  • Any dependent changes have been merged

Further comments

If this is a relatively large or complex change, kick off the discussion at dev@doris.apache.org by explaining why you chose the solution you did and what alternatives you considered, etc...

Table table = db.getTable(tableId);
// delete from db meta
db.writeLock();
if (table == null) {
Copy link
Contributor

Choose a reason for hiding this comment

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

move it before db.writeLock();

Copy link
Contributor

@morningman morningman left a comment

Choose a reason for hiding this comment

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

LGTM

@morningman morningman added approved Indicates a PR has been approved by one committer. kind/fix Categorizes issue or PR as related to a bug. labels Jun 8, 2021
@morningman morningman merged commit c95bebf into apache:master Jun 9, 2021
@zh0122 zh0122 deleted the fix_npe branch June 9, 2021 06:25
morningman pushed a commit that referenced this pull request Sep 3, 2021
…6416)

fix #5378 #5391 #5688 #5973 #6155 and all replay NPE. All replay method can now throw MetaNotFoundException and caught to log a warning for potential inconsistent metadata cases.

try to establish a clear notice for future developer to check null.
EmmyMiao87 pushed a commit to EmmyMiao87/incubator-doris that referenced this pull request Nov 10, 2021
Although the table lock can control the simultaneous modification of the table by different threads.
But it cannot control the drop operation of the table by other threads.
For example, when drop table and table update occur at the same time.

get table object by thread 1
drop table by thread 2 with table lock
update table object by thread 1
The above process is possible.
At this time, step 3 actually operates a table that no longer exists, which will eventually cause NullPointerException.

In fact, the modified table log after the drop table can be ignored. The reason is that it is meaningless to modify information on a table that no longer exists.

Fixed apache#5687
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

approved Indicates a PR has been approved by one committer. area/editlog-replay kind/fix Categorizes issue or PR as related to a bug.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Replay update replica failed when table has been dropped

3 participants