[
https://issues.apache.org/jira/browse/FLINK-24182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17417558#comment-17417558
]
Piotr Nowojski commented on FLINK-24182:
----------------------------------------
{quote}
no more interruption once the task exited its main loop and is closing
operators. Basically shouldInterruptOnCancel = false; should be moved earlier
in the StreamTask. If task is already closing, interrupting can lead to
resource leaks. So if task is stuck in closing, the only thing we can do is to
fail whole JVM.
{quote}
In the end I think we should keep the interruptions, as we don't have a clean
way to cancel a code stuck in the user code (back pressured Sinks, or blocked
user functions/operators).
Disabling interrupts when closing operators should be already enough to solve
the reported by [~arvid] issue.
> Tasks canceler should not immediately interrupt
> -----------------------------------------------
>
> Key: FLINK-24182
> URL: https://issues.apache.org/jira/browse/FLINK-24182
> Project: Flink
> Issue Type: Improvement
> Components: Runtime / Task
> Reporter: Arvid Heise
> Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
> While debugging resource leaks (FLINK-24131), I found that any connector is
> immediately interrupted on cancel. Hence, any attempts of using blocking
> calls in {{close}} to cleanup resources are immediately unreliable (e.g.
> aborting transactions).
> It would be nice if tasks get a grace period (e.g.
> task.cancellation.interval) where they can try to free resources in a proper,
> potentially blocking fashion before being interrupted.
> Nevertheless, connectors should always expect interruptions during shutdown,
> in particular when the user-configurable grace period is depleted. I'd add
> that to the connector documentation in a separate effort.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
