You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@samza.apache.org by "Jake Maes (JIRA)" <ji...@apache.org> on 2017/08/04 17:52:00 UTC
[jira] [Created] (SAMZA-1384) Race condition with async commit
affects checkpoint correctness
Jake Maes created SAMZA-1384:
--------------------------------
Summary: Race condition with async commit affects checkpoint correctness
Key: SAMZA-1384
URL: https://issues.apache.org/jira/browse/SAMZA-1384
Project: Samza
Issue Type: Bug
Reporter: Jake Maes
Assignee: Jake Maes
Fix For: 0.14.0
Consider two threads A and B. A is performing an async commit. B is an in-flight process(). The following sequence will cause data loss:
1. A: TaskInstance.commit() begins
2. A: producer.flush() is called // no new messages will go out in this batch
3. B: producer.send() is called
4. B: TaskCallback is invoked for the finished process()
5. B: OffsetManager records the offset for the completed process()
6. A: producer.flush() finishes
7. A: checkpoint is written using the latest offsets from the OffsetManager. This INCLUDES the offset for the latest send, which has not yet gone out over the wire.
8. A: TaskInstance.commit() finishes
8. B: producer.send()->callback is invoked with an error. Send was unsuccessful, but has been checkpointed already.
9. B: Exception is propagated and container fails
10. Container is restarted and starts from the last checkpoint.
Note that this is only an issue when the commit() occurs concurrently with in-flight requests, so it doesn't affect the fully-synchronous mode or concurrent mode with synchronous commit().
Proposed solution:
Take a snapshot of the offsets in the OffsetManager at the beginning of commit(). Only checkpoint those offsets and nothing new that has been sent since the commit() started.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)