[
https://issues.apache.org/jira/browse/FLINK-8984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16404966#comment-16404966
]
ASF GitHub Bot commented on FLINK-8984:
---------------------------------------
Github user pnowojski commented on the issue:
https://github.com/apache/flink/pull/5708
Yes, it's a valid setting, but has worse performance and whole credit based
flow control looses it's sense.
`taskmanager.exactly-once.blocking.data.enabled` setting was thought as a
fallback option if there is a bug in new code path, but this is achieved by
using `taskmanager.network.credit-based-flow-control.enabled` in two places
(and both of those places are about using `credit-based-flow-control`).
In other words, we do not think there is a much value in allowing
`taskmanager.network.credit-based-flow-control.enabled` enabled, but
`taskmanager.exactly-once.blocking.data.enabled`
disabled, and it would make the configuration more complex/confusing for
the users.
> Disabling credit based flow control deadlocks Flink on checkpoint
> -----------------------------------------------------------------
>
> Key: FLINK-8984
> URL: https://issues.apache.org/jira/browse/FLINK-8984
> Project: Flink
> Issue Type: Bug
> Components: Network
> Affects Versions: 1.5.0
> Reporter: Piotr Nowojski
> Assignee: Piotr Nowojski
> Priority: Blocker
> Fix For: 1.5.0
>
>
> This is configuration issue. There are two options:
> taskmanager.network.credit-based-flow-control.enabled
> and
> taskmanager.exactly-once.blocking.data.enabled
> If we disable first one, but remain default value for the second one
> deadlocks will occur. I think we can safely drop the second config value
> altogether and always use blocking BarrierBuffer for credit based flow
> control and spilling BarrierBuffer for non credit based flow control.
> cc [~zjwang]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
