[
https://issues.apache.org/jira/browse/KAFKA-3658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15276583#comment-15276583
]
Guozhang Wang commented on KAFKA-3658:
--------------------------------------
Actually it is not about a policy change, we previously we thought it is
required that retention size >= window size * 2 simply due to segmenting
mechanism, that with a minimum of 3 segments, we want to keep the segment size
= (retention size) / (number of segments - 1) to be no smaller than the window
size; I realized that it is not necessary for the current setting: for
aggregate windows they will all locates in one segment since we use
window-start-timestamp as timestamp, and for join windows we will not care
since after the retention period the window is gone.
> Incorrect validation check on maintenance period with join window size
> ----------------------------------------------------------------------
>
> Key: KAFKA-3658
> URL: https://issues.apache.org/jira/browse/KAFKA-3658
> Project: Kafka
> Issue Type: Bug
> Components: streams
> Reporter: Guozhang Wang
> Assignee: Guozhang Wang
> Labels: architecture
> Fix For: 0.10.0.1
>
>
> As [~h...@pinterest.com] found out, the current validation check of
> {{KStreamJoinWindow}} requires the retention period to be at least twice than
> the join window size. This check was originally for making the segment
> interval to be larger than the join window size. But for windowed
> stream-stream join this is not necessary.
> More specifically, for example with a window size 6, and retention period 12,
> and num. segment 5, the segment size will be set to 3. This means after time
> 12, the first segment of [0, 3) will be dropped, then at time 13, a late
> record with timestamp (1) will not be accepted to the window store, and will
> not participate in the joining as well.
> The proposed change is to only require retention period to be > window size,
> not window size * 2.
> cc [~ymatsuda]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
