Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id E229D200D0A for ; Tue, 19 Sep 2017 12:17:49 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id E09551609DD; Tue, 19 Sep 2017 10:17:49 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 312BD1609DB for ; Tue, 19 Sep 2017 12:17:49 +0200 (CEST) Received: (qmail 18587 invoked by uid 500); 19 Sep 2017 10:17:48 -0000 Mailing-List: contact user-help@flink.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list user@flink.apache.org Received: (qmail 18576 invoked by uid 99); 19 Sep 2017 10:17:48 -0000 Received: from mail-relay.apache.org (HELO mail-relay.apache.org) (140.211.11.15) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 19 Sep 2017 10:17:48 +0000 Received: from aljoschas-mbp.fritz.box (dslb-094-222-124-158.094.222.pools.vodafone-ip.de [94.222.124.158]) by mail-relay.apache.org (ASF Mail Server at mail-relay.apache.org) with ESMTPSA id 387821A0185; Tue, 19 Sep 2017 10:17:45 +0000 (UTC) From: Aljoscha Krettek Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_6433FE1D-EA15-4A2F-9F89-9C7914703FA5" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Clean GlobalWidnow state Date: Tue, 19 Sep 2017 12:17:41 +0200 In-Reply-To: Cc: gerardg , user To: =?utf-8?Q?Fabian_H=C3=BCske?= References: <1505468364022-0.post@n4.nabble.com> <68D5FB4F-73E1-4E2E-B6D1-E6F9799D8892@apache.org> <1505470811244-0.post@n4.nabble.com> <1505480624080-0.post@n4.nabble.com> <1505741267520-0.post@n4.nabble.com> <1505813534071-0.post@n4.nabble.com> X-Mailer: Apple Mail (2.3273) archived-at: Tue, 19 Sep 2017 10:17:50 -0000 --Apple-Mail=_6433FE1D-EA15-4A2F-9F89-9C7914703FA5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, Are the UUIDs randomly generated when calling .uuid or are they assigned = and then .uuid will return the same UUID when calling multiple times? = The latter would be problematic because we would not correctly assign = state. Best, Aljoscha > On 19. Sep 2017, at 11:41, Fabian Hueske wrote: >=20 > If this would be the case, that would be a bug in Flink. > As I said before, your implementation looked good to me. > All state of window and trigger should be wiped if the trigger returns = FIRE_AND_PURGE (or PURGE) and it's clean() method is correctly = implemented.=20 >=20 > I'll CC Aljoscha again for his opinion.=20 > We might need to file a JIRA for the issue. >=20 > Thanks,=20 > Fabian >=20 > 2017-09-19 11:32 GMT+02:00 gerardg >: > Thanks Fabian, I'll take a look to these improvements. >=20 > I was wondering if the increasing state size could be due to that the = UUID > used in the keyBy are randomly generated. Maybe even if I correctly = delete > all the state related to a given key there is still some metadata = related to > the key wandering around. >=20 > Gerard >=20 >=20 >=20 > -- > Sent from: = http://apache-flink-user-mailing-list-archive.2336050.n4.nabble.com/ = >=20 --Apple-Mail=_6433FE1D-EA15-4A2F-9F89-9C7914703FA5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi,

Are = the UUIDs randomly generated when calling .uuid or are they assigned and = then .uuid will return the same UUID when calling multiple times? The = latter would be problematic because we would not correctly assign = state.

Best,
Aljoscha
On = 19. Sep 2017, at 11:41, Fabian Hueske <fhueske@gmail.com> = wrote:

If this would be the case, that would be a = bug in Flink.
As I said before, your implementation = looked good to me.
All state of window and trigger should be wiped = if the trigger returns FIRE_AND_PURGE (or PURGE) and it's clean() method = is correctly implemented.

I'll CC = Aljoscha again for his opinion.
We = might need to file a JIRA for the issue.

Thanks,
Fabian

2017-09-19 11:32 GMT+02:00 gerardg <gerard@talaia.io>:
Thanks Fabian, I'll take a look to these = improvements.

I was wondering if the increasing state size could be due to that the = UUID
used in the keyBy are randomly generated. Maybe even if I correctly = delete
all the state related to a given key there is still some metadata = related to
the key wandering around.

Gerard



--
Sent from: http://apache-flink-user-mailing-list-archive.2336050.n4.nabble.com/


= --Apple-Mail=_6433FE1D-EA15-4A2F-9F89-9C7914703FA5--