SmirAlex commented on PR #23521: URL: https://github.com/apache/flink/pull/23521#issuecomment-1814413557
Thanks for the response, @Sxnan. I got your points. BTW, the reason why delivery guarantees of `RecordAttributes` elements to downstream operators was important to me is that I was testing the possibility to use them in order to properly implement Processing Time Temporal Join. I [described](https://lists.apache.org/thread/b3doy1gqchv45g2vjxcblv10two9gvsv) my thoughts about this in [FLIP-326](https://cwiki.apache.org/confluence/display/FLINK/FLIP-326%3A+Enhance+Watermark+to+Support+Processing-Time+Temporal+Join) discussion thread. Thus, if eventually it will be decided to reuse `RecordAttributes` logic in order to solve [FLINK-19830](https://issues.apache.org/jira/browse/FLINK-19830), the problem I described will arise one way or another. Also, I should mention that there is another workaround that guarantees delivery of `RecordAttributes(isBacklog=false)` (but not isBacklog=true), but at the same time prevents considering some non-backlog records as backlog records. Pseudocode may be like this: ``` if (lastOutputAttributes == null && nonBacklogChannelsCnt == numInputChannels) { nonBacklogChannelsCnt = 0; output.emitRecordAttributes(RecordAttributes(isBacklog=false)); } ``` The downside is that it is possible to have `RecordAttributes(isBacklog=false)` without `RecordAttributes(isBacklog=true)` previously, but probably, it's ok. In other respects, this approach worked fine for me. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@flink.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
