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

Call the OnFlushCompleted handler unconditionally #5207

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

BenHuddleston
Copy link

#5206

In the case of a shutdown or other reasons in which a flush may
not complete, OnFlushCompleted is not called because the Status is
not OK. Instead, pass the status through to the event listener via the
FlushJobInfo and allow the listener to deal with any failure as they
see fit.

In the case of a shutdown or other reasons in which a flush may
not complete, OnFlushCompleted is not called because the Status is
not OK. Instead, pass the status through to the event listener via the
FlushJobInfo and allow the listener to deal with any failure as they
see fit.
Copy link
Contributor

@anand1976 anand1976 left a comment

Choose a reason for hiding this comment

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

I'm concerned about the behavior change to call OnFlushCompleted unconditionally, when historically we've only called it on success. I think its the correct behavior, but it might create issues if users have been relying on this handler to track SST files created by a flush. We have the OnTableFileCreated listener for that purpose, but not everyone might have switched over.

@siying Your thoughts? Is it safe to call it unconditionally?

@siying
Copy link
Contributor

siying commented Sep 9, 2019

@riversand963 knows more history about the flush listeners. @ajkr should know the best but I'm not sure whether he can help:)

@riversand963
Copy link
Contributor

I share similar concerns with @anand1976, but I think it's feasible to fix. It sounds like correct behavior and we may need to add a status field to FlushJobInfo. Users who will likely be affected by this behavior change can update the logic in OnFlushCompleted().
Just not sure whether we should postpone this public-facing, behavior change until next release.

@anand1976
Copy link
Contributor

@riversand963 By next release, do you mean next major release, i.e 7.0?

@riversand963
Copy link
Contributor

Yes, I wonder whether we should review it now, but postpone the merge until 7.0, assuming we allow public-facing behavior change only upon major releases.

@anand1976
Copy link
Contributor

I agree with postponing the merge until 7.0. I'm not sure how we can track it though. Maybe create a new label "Postpone to next major release" and apply it to this PR?

@riversand963
Copy link
Contributor

How about using tag or milestone?

@anand1976 anand1976 added this to the 7.0.0 milestone Sep 11, 2019
@riversand963
Copy link
Contributor

@anand1976 are we still going to merge this?

@anand1976
Copy link
Contributor

@anand1976 are we still going to merge this?

@riversand963 Mempurge introduces another complication. Currently, we don't call OnFlushCompleted() if the flush resulted in a mempurge instead. If we call it, I don't know what the status should be.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants