[
https://issues.apache.org/jira/browse/FLINK-6316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Flink Jira Bot updated FLINK-6316:
----------------------------------
Labels: auto-deprioritized-major auto-deprioritized-minor (was:
auto-deprioritized-major stale-minor)
Priority: Not a Priority (was: Minor)
This issue was labeled "stale-minor" 7 days ago and has not received any
updates so it is being deprioritized. If this ticket is actually Minor, please
raise the priority and ask a committer to assign you the issue or revive the
public discussion.
> Kinesis connector docs should mention that FlinkKinesisConsumer does not
> provide strong ordering guarantees on resharding
> -------------------------------------------------------------------------------------------------------------------------
>
> Key: FLINK-6316
> URL: https://issues.apache.org/jira/browse/FLINK-6316
> Project: Flink
> Issue Type: Improvement
> Components: Connectors / Kinesis, Documentation
> Reporter: Tzu-Li (Gordon) Tai
> Priority: Not a Priority
> Labels: auto-deprioritized-major, auto-deprioritized-minor
>
> Since the {{FlinkKinesisConsumer}} depends only on local information to
> determine whether or not a new shard due to resharding should be subscribed
> by a subtask, there is no coordination wrt parent-child shard relationship
> across subtasks.
> Therefore, {{FlinkKinesisConsumer}} does not provide any strong processing
> ordering guarantees.
> Take for example, if initially the assignment is:
> Subtask #1 --> Shard A
> Subtask #2 --> Shard B
> Assume A & B is merged to create shard C, and subtask #1 locally determines
> that it should be assigned shard C.
> Since Flink generally does not provide coordinating facilities between
> subtask instances, there is no means of coordinating that shard C is consumed
> only after shard B is also fully consumed.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
