waitinfuture opened a new pull request, #1808:
URL: https://github.com/apache/incubator-celeborn/pull/1808
…losed to avoid data lost
<!--
Thanks for sending a pull request! Here are some tips for you:
- Make sure the PR title start w/ a JIRA ticket, e.g. '[CELEBORN-XXXX]
Your PR title ...'.
- Be sure to keep the PR description updated to reflect all changes.
- Please write your PR title to summarize what this PR proposes.
- If possible, provide a concise example to reproduce the issue for a
faster review.
-->
### What changes were proposed in this pull request?
This PR fixes a bug that in rare cases it may cause data lost.
### Why are the changes needed?
I received a bug report from one of the users that in an extreme case small
data lost happens. I
reproduced the bug under the following conditions:
1. Shuffle data size for one partition id is relatively large, for example
400GB
2. `celeborn.client.shuffle.partitionSplit.mode` is set to HARD
3. `celeborn.client.shuffle.batchHandleCommitPartition.enabled` is enabled
At the mean time, there are warning messages in worker's log
```
23/08/11 17:10:04,501 WARN [push-server-6-44] PushDataHandler: Append data
failed for task(shuffle application_1691635581416_0021-0, map 746, attempt 0),
caused by AlreadyClosedException, endedAttempt -1, error message: FileWriter
has already closed!, fileName
/mnt/disk1/celeborn-worker/shuffle_data/application_1691635581416_0021/0/0-107-0
23/08/11 17:12:04,445 WARN [push-server-6-35] PushDataHandler: Append data
failed for task(shuffle application_1691635581416_0021-0, map 3016, attempt 0),
caused by AlreadyClosedException, endedAttempt -1, error message: FileWriter
has already closed!, fileName
/mnt/disk3/celeborn-worker/shuffle_data/application_1691635581416_0021/0/0-356-0
```
After digging into it, I found the reason for the data lost is as follows:
1. For some partition id in some worker, the file size exceeds
`celeborn.client.shuffle.partitionSplit.threshold`, then
`CommitManager` in `LifecycleManager` will trigger `CommitFiles` because
`batchHandleCommitPartition` is enabled
2. Before `CommitFile` finishes, `PushDataHandler` receives `PushData` or
`PushMergedData`, it finds that the partition has not committed yet, and is
preparing to call `fileWriter.incrementPendingWrites()` and `callback.onSuccess`
3. Before `PushDataHandler` calls `fileWriter.incrementPendingWrites()`, the
`CommitFiles` finishes and the FileWriter
successfully closes.
4. Then `PushDataHandler` calls `fileWriter.incrementPendingWrites()` and
`callback.onSuccess`. After this time,
`ShuffleClient` thinks the `PushData` succeeds. However, when
`PushDataHandler` calls `fileWriter.write()`, it
finds it already closed and throws the above exception. However, the
exception is ignored, so the data lost happens.
This PR fixes this by checking whether FileWriter has closed after calling
`incrementPendingWrites`. If true,
`PushDataHandler` calls `onFailure`.
### Does this PR introduce _any_ user-facing change?
No.
### How was this patch tested?
Manual test.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
