hance the state was not registered
> „fast
> >>> enough“. As I see it, the proper way is the register the state under
> the
> >>> same name and clear it if you want to get rid of the data. There is
> >>> currently no call that explicitly drops a state that
urrently no call that explicitly drops a state that was once declared, and
>> you might make a case that this is a feature to have for the future. Then
>> again, we need a general decision about lazy and eager state IMO.
>>
>> Best,
>> Stefan
>>
>>>
e future. Then
>>> again, we need a general decision about lazy and eager state IMO.
>>>
>>> Best,
>>> Stefan
>>>
>>>> Am 22.02.2018 um 11:10 schrieb Gyula Fóra :
>>>>
>>>> Hi all,
>>>>
>>>&g
Best,
> Stefan
>
> > Am 22.02.2018 um 11:10 schrieb Gyula Fóra :
> >
> > Hi all,
> >
> > We have discovered a fairly serious memory leak
> > in DefaultOperatorStateBackend, with broadcast (union) list states.
> >
> > The problem seems to occur when
Am 22.02.2018 um 11:10 schrieb Gyula Fóra :
>
> Hi all,
>
> We have discovered a fairly serious memory leak
> in DefaultOperatorStateBackend, with broadcast (union) list states.
>
> The problem seems to occur when a broadcast state name is changed, in order
> to drop some state
Hi all,
We have discovered a fairly serious memory leak
in DefaultOperatorStateBackend, with broadcast (union) list states.
The problem seems to occur when a broadcast state name is changed, in order
to drop some state (intentionally).
Flink does not drop the "garbage" broadcast
