[
https://issues.apache.org/jira/browse/FLINK-1754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14384450#comment-14384450
]
Stephan Ewen commented on FLINK-1754:
-------------------------------------
Is this issue resolved?
The issue with deadlocks in 0.8.1 is (I think) that the runtime does not obey
the assumptions from the optimizer. The hash table building requires (for some
reason) data availability on the probe side as well.
> Deadlock in job execution
> -------------------------
>
> Key: FLINK-1754
> URL: https://issues.apache.org/jira/browse/FLINK-1754
> Project: Flink
> Issue Type: Bug
> Affects Versions: 0.8.1
> Reporter: Sebastian Kruse
>
> I have encountered a reproducible deadlock in the execution of one of my
> jobs. The part of the plan, where this happens, is the following:
> {code:java}
> /** Performs the reduction via creating transitive INDs and removing them
> from the original IND set. */
> private DataSet<Tuple2<Integer, int[]>>
> calculateTransitiveReduction1(DataSet<Tuple2<Integer, int[]>>
> inclusionDependencies) {
> // Concatenate INDs (only one hop).
> DataSet<Tuple2<Integer, int[]>> transitiveInds = inclusionDependencies
> .flatMap(new SplitInds())
> .joinWithTiny(inclusionDependencies)
> .where(1).equalTo(0)
> .with(new ConcatenateInds());
> // Remove the concatenated INDs to come up with a transitive
> reduction of the INDs.
> return inclusionDependencies
> .coGroup(transitiveInds)
> .where(0).equalTo(0)
> .with(new RemoveTransitiveInds());
> }
> {code}
> Seemingly, the flatmap operator waits infinitely for a free buffer to write
> on.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
