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-1866][Flink] Fix CelebornChannelBufferReader request more buffers than needed #3102

Closed
wants to merge 1 commit into from

Conversation

codenohup
Copy link
Contributor

@codenohup codenohup commented Feb 17, 2025

What changes were proposed in this pull request?

I found a case where a Flink job is hanging which utilize Celeborn hybrid integration strategy.

The issue seems to be that the CelebornChannelBufferReader is requesting more buffers than needed, which prevents other readers from getting enough buffers to continue reading data. This problem usually happens when memory competition is high.

When other readers recycle buffers back to the LocalBufferPool, the LocalBufferPool calls CelebornChannelBufferManager#notifyBufferAvailable to notify about the available buffer, and then CelebornChannelBufferManager requests buffers from the LocalBufferPool.

For instance, if CelebornBufferManager#numRequiredBuffers is set to 5 and it only gets 4 buffers from the LocalBufferPool, it won't immediately decrease numRequiredBuffers to 1. Instead, it will keep trying to request more buffers from the LocalBufferPool until it exits the synchronized block, at which point it will reduce numRequiredBuffers.

I think the bug occurs when the CelebornBufferManager exits the synchronized block. If a reader requests a buffer from this CelebornBufferManager, the number of buffers in BufferManager#bufferQueue _drops from 4 to 3. When the _LocalBufferPool has buffers again and tries to offer them to the CelebornBufferManager, the CelebornBufferManager mistakenly thinks it should request 2 buffers instead of just 1.

Why are the changes needed?

It may cause flink job hang.

Does this PR introduce any user-facing change?

no.

How was this patch tested?

We have a job that can reproduce this case. After the fix, it can be completed stably.

@reswqa reswqa closed this in f1eec65 Feb 19, 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