[ 
https://issues.apache.org/jira/browse/FLINK-21817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17306669#comment-17306669
 ] 

Jiangjie Qin commented on FLINK-21817:
--------------------------------------

I think solution 1 and 2 [~renqs] mentioned do not conflict with each other. 
They are more like two steps. In another word, it is the enumerator's call 
whether it wants to adjust the splits assignment after the readers reported the 
assignment upon reader registration. Revoking a split assignment seems a useful 
primitive for other cases as well, e.g. workload balance.

So to fix the inconsistent state, we only need to do (1).

> New Kafka Source might break subtask and split assignment upon rescale
> ----------------------------------------------------------------------
>
>                 Key: FLINK-21817
>                 URL: https://issues.apache.org/jira/browse/FLINK-21817
>             Project: Flink
>          Issue Type: Bug
>          Components: Connectors / Common
>    Affects Versions: 1.12.2
>            Reporter: Kezhu Wang
>            Priority: Blocker
>             Fix For: 1.13.0, 1.12.3
>
>
> On restoring, splits are add back directly to {{SourceReader}} in 
> {{SourceOperator}}. In no rescaled restoring, bindings between splits and 
> subtasks are preserved due to no repartition in 
> {{RoundRobinOperatorStateRepartitioner}}. But in rescaled restoring, these 
> operator states will be redistributed cross existing subtasks. This might 
> break possible assignment from {{SourceEnumerator}}.
> Given {{KafkaSource}} as an example, the partition to subtask assignment is 
> decided by {{KafkaSourceEnumerator.getSplitOwner}}. The mappings will break 
> after rescaling.
> I pushed [a test 
> case|https://github.com/kezhuw/flink/commit/9dc13cd9d7355d468a6ac8aae1b14b3a267581b6#diff-ad6e86c3757199ac3247687a71f9c34ee67b9ac743ae88a9f660950f27bec6eeR238]
>  using {{KafkaSource}} for evaluation.
> I think it requires api addition to solve in generic and configurable way.
> Is it a valid issue ? I am not that sure.
> cc  [~jqin] [~sewen]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to