Moved this KIP into status "inactive". Feel free to resume and any time.
-Matthias
On 1/9/19 10:18 PM, Guozhang Wang wrote:
> Hello Lei,
>
> Just checking what's the current status of this KIP. We have a KIP deadline
> for 2.2 on 24th and wondering if this one may be able to make it.
>
>
>
Hello Lei,
Just checking what's the current status of this KIP. We have a KIP deadline
for 2.2 on 24th and wondering if this one may be able to make it.
Guozhang
On Sat, Dec 15, 2018 at 1:01 PM Lei Chen wrote:
> Sorry for the late reply Matthias. Have been busy with other work recently.
>
Sorry for the late reply Matthias. Have been busy with other work recently.
I'll restart the discussion and update the KIP accordingly.
Lei
On Tue, Nov 6, 2018 at 3:11 PM Matthias J. Sax
wrote:
> Any update on this KIP?
>
> On 9/20/18 3:30 PM, Matthias J. Sax wrote:
> > Thanks for following
Any update on this KIP?
On 9/20/18 3:30 PM, Matthias J. Sax wrote:
> Thanks for following up. Very nice examples!
>
> I think, that the window definition for Flink is semantically
> questionable. If there is only a single record, why is the window
> defined as [ts, ts+gap]? To me, this
Thanks for following up. Very nice examples!
I think, that the window definition for Flink is semantically
questionable. If there is only a single record, why is the window
defined as [ts, ts+gap]? To me, this definition is not sound and seems
to be arbitrary. To define the windows as
Thanks Matthias. That makes sense.
You're right that symmetric merge is necessary to ensure consistency. On
the other hand, I kinda feel it defeats the purpose of dynamic gap, which
is to update the gap from old value to new value. The symmetric merge
always honor the larger gap in both
Thanks for explaining your understanding. And thanks for providing more
details about the use-case. Maybe you can add this to the KIP?
First one general comment. I guess that my and Guozhangs understanding
about gap/close/gracePeriod is the same as yours -- we might not have
use the term
Hello Lei,
As Matthias mentioned, the key question here is that because of the late
arrivals of records which may indicate a shorter session gap interval, some
session windows may be "mistakenly" merged and hence need to be undone the
merge, i.e. to split them again.
Back to my example, you are
I cannot follow the example:
>> (10, 10), (15, 3), (19, 5) ...
First, [10,10] is created, second the window is extended to [10,15], and
third [19,19] is created. Why would there be a [15,15]? And why would
(19,5) be merged into [15,15] -- the gap was set to 3 via (15,3) and
thus [19,19] should
Hi Guozhang,
Thanks for reviewing the proposal. I didn't think of out of order events
and glad that you brought it up.
In the example you gave,
(10, 10), (19, 5), (15, 3) ...
my understanding is that the correct result window should be the same as in
order events
(10, 10), (15, 3), (19, 5)
Hello Lei,
Thanks for the proposal. I've just made a quick pass over it and there is a
question I have:
The session windows are defined per key, i.e. does that mean that each
incoming record of the key can dynamically change the gap of the window?
For example, say you have the following record
Hi All,
I created a KIP to add dynamic gap session window support to Kafka Streams
DSL.
https://cwiki.apache.org/confluence/display/KAFKA/KIP-362%3A+Support+dynamic+gap+session+window
Please take a look,
Thanks,
Lei
12 matches
Mail list logo
