A quickfix would be to take the first join and give it a
"JoinHint.REPARTITION_HASH_BUILD_SECOND" hint.
The best thing would be to have batch exchanges for iterations.
The second best thing would be to recognize in the optimizer that a batch
exchange cannot happen (if inside an iteration) and i
> On 08 Sep 2015, at 10:12, Schueler, Ricarda
> wrote:
>
> Hi,
>
> we tested it with the version 0.9.1, but unfortunately the issue persists.
Thanks for helping me out debugging this Ricarda! :)
From what I can tell, this is not a deadlock in the network runtime, but a join
deadlock within
> On 08 Sep 2015, at 10:41, Ufuk Celebi wrote:
>
> Hey Ricarda,
>
> I will try to reproduce this locally with the data sets in your repo.
I just saw that the data is very small. Can you point me to a data set to
reproduce?
> we tested it with the version 0.9.1, but unfortunately the issue persists.
>
> Best
> Ricarda
>
> Von: ewenstep...@gmail.com im Auftrag von Stephan
> Ewen
> Gesendet: Montag, 7. September 2015 00:39
> An: user@flink.apache.org
> Betreff: Re: Memory management i
Hi!
Can you switch to version 0.9.1? That one included some bug fixes,
including one or two possible deadlock situations.
Please let us know if that solves the issue, or if the issue persists...
Greetings,
Stephan
On Fri, Sep 4, 2015 at 7:19 PM, Ricarda Schueler <
ricarda.schue...@student.hpi.
