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

[CELEBORN-1818] Fix incorrect timeout exception when waiting on no pending writes #3049

Closed

Conversation

littlexyw
Copy link

What changes were proposed in this pull request?

Do not throw "Wait pending actions timeout" exception when waiting pending writes times out.

Why are the changes needed?

When pendingWrites is reduced to zero, the method waitOnNoPending will jump out of the while loop. Meanwhile, if new PushData/PushMergedData request comes, pendingWrites will increment and be larger then zero. As a result, "wait pending actions timeout" exception will be thrown in waitOnNoPending.

Does this PR introduce any user-facing change?

No

How was this patch tested?

manual test

@cfmcgrady cfmcgrady changed the title [CELEBORN-1818]Fix incorrect timeout exception when waiting on no pending writes [CELEBORN-1818] Fix incorrect timeout exception when waiting on no pending writes Jan 3, 2025
@@ -507,7 +507,7 @@ protected synchronized long close(
}

try {
waitOnNoPending(numPendingWrites);
waitOnNoPending(numPendingWrites, false);
Copy link
Contributor

Choose a reason for hiding this comment

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

Seems we no longer need to waitOnNoPending writes, only need waitOnNoPending flushes.

Copy link
Author

Choose a reason for hiding this comment

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

Seems we no longer need to waitOnNoPending writes, only need waitOnNoPending flushes.

If waitOnNoPending writes is removed, I'm afraid there will be more unnecessary "file already closed" exception and revive operation.

Copy link
Contributor

Choose a reason for hiding this comment

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

Sounds reasonable, but maybe someone else need to take a look as well.

Copy link
Contributor

@RexXiong RexXiong left a comment

Choose a reason for hiding this comment

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

LGTM

Copy link
Contributor

@FMX FMX left a comment

Choose a reason for hiding this comment

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

LGTM. After some offline discussion with @RexXiong, I think this implementation should be fine.

@FMX FMX closed this in 61c90e3 Jan 7, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants