[
https://issues.apache.org/jira/browse/FLINK-13581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16900684#comment-16900684
]
Andrey Zagrebin commented on FLINK-13581:
-----------------------------------------
[~till.rohrmann]
According to logs, I think the reason is the following. Task managers of the
mini cluster are started with a random data port. All TMs have the same local
host.
In this particular run the first TM and the second one were started
accidentally with the same port. When the failure of the first TM was generated
and the second TM was started, the partition request from the redeployed
consuming mapper came to the second TM because of the accidental port match.
This led to a partition-not-found response as the partition resided on the
first TM and subsequently led to an async re-triggering of the partition
request. In this case task proceeds with the user code. Therefore, this was
counted as one extra mapper restart in the open method.
Usually, the random data ports always differ for each subsequently started TM
after failing the previous one. This always leads to a connection failure of
the first partition request and fails the whole Task without entering the user
code. The user code is not entered because the partition request was recently
moved to gate setup before invoking the user code. Eventually mapper restart is
not counted in normal case.
> BatchFineGrainedRecoveryITCase failed on Travis
> -----------------------------------------------
>
> Key: FLINK-13581
> URL: https://issues.apache.org/jira/browse/FLINK-13581
> Project: Flink
> Issue Type: Bug
> Components: Runtime / Coordination
> Affects Versions: 1.9.0
> Reporter: Andrey Zagrebin
> Assignee: Andrey Zagrebin
> Priority: Blocker
> Labels: test-stability
> Fix For: 1.9.0
>
>
> [https://travis-ci.com/flink-ci/flink/jobs/221567908]
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
