You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jira@kafka.apache.org by "bounkong khamphousone (Jira)" <ji...@apache.org> on 2022/03/15 09:30:00 UTC

[jira] [Created] (KAFKA-13739) Sliding window without grace not working

bounkong khamphousone created KAFKA-13739:
---------------------------------------------

             Summary: Sliding window without grace not working
                 Key: KAFKA-13739
                 URL: https://issues.apache.org/jira/browse/KAFKA-13739
             Project: Kafka
          Issue Type: Bug
          Components: streams
    Affects Versions: 3.1.0
            Reporter: bounkong khamphousone


Hi everyone! I would like to understand why KafkaStreams DSL offer the ability to express a SlidingWindow with no grace period but seems that it doesn't work. [confluent's site|https://docs.confluent.io/platform/current/streams/developer-guide/dsl-api.html#sliding-time-windows] state that grace period is required and with the deprecated method, it's default to 24 hours.

Doing a basic sliding window with a count, if I set grace period to 1 ms, expected output is done. Based on the sliding window documentation, lower and upper bounds are inclusive.

If I set grace period to 0 ms, I can see that record is not skipped at KStreamSlidingWindowAggregate(l.126) but when we try to create the window and push the event in KStreamSlidingWindowAggregate#createWindows we call the method updateWindowAndForward(l.417). This method (l.468) check that {{{}windowEnd > closeTime{}}}.

closeTime is defined as {{observedStreamTime - window.gracePeriodMs}} (Sliding window configuration)

windowEnd is defined as {{{}inputRecordTimestamp{}}}.

 

For a first event with a record timestamp, we can assume that observedStreamTime is equal to inputRecordTimestamp.

 

Therefore, closeTime is {{inputRecordTimestamp - 0}} (gracePeriodMS) which results to {{{}inputRecordTimestamp{}}}.

If we go back to the check done in {{updateWindowAndForward}} method, then we have inputRecordTimestamp > inputRecordTimestamp which is always false. The record is then skipped for record's own window.

Stating that lower and upper bounds are inclusive, I would have expected the event to be pushed in the store and forwarded. Hence, the check would be {{{}windowEnd >= closeTime{}}}.

 

Is it a bug or is it intended ?

Thanks in advance for your explanations!

Best regards!



--
This message was sent by Atlassian Jira
(v8.20.1#820001)