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,
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 issue
Hi
hue...@student.hpi.uni-potsdam.de> wrote:
>
> Hi All,
>
> We're running into a memory management issue when using the
> iterateWithTermination function.
> Using a small amount of data, everything works perfectly fine. However,
> as soon as the main memory is filled up on a worker, not
Hi All,
We're running into a memory management issue when using the
iterateWithTermination function.
Using a small amount of data, everything works perfectly fine. However,
as soon as the main memory is filled up on a worker, nothing seems to be
happening any more. Once this happens, any w
