[
https://issues.apache.org/jira/browse/FLINK-12351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17180345#comment-17180345
]
Piotr Nowojski commented on FLINK-12351:
----------------------------------------
I think this is a valid concern. I'm not sure how much performance impact
matters here (probably not much judging by the common AsyncWaitOperator
usecases). We we could try to avoid the deepcopy overhead when the operator is
the head of the chain, but I'm not sure how elegant would it be to depend on
such behaviour.
> AsyncWaitOperator should deep copy StreamElement when object reuse is enabled
> -----------------------------------------------------------------------------
>
> Key: FLINK-12351
> URL: https://issues.apache.org/jira/browse/FLINK-12351
> Project: Flink
> Issue Type: Bug
> Components: API / DataStream
> Reporter: Jark Wu
> Assignee: Jark Wu
> Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently, AsyncWaitOperator directly put the input StreamElement into
> {{StreamElementQueue}}. But when object reuse is enabled, the StreamElement
> is reused, which means the element in {{StreamElementQueue}} will be
> modified. As a result, the output of AsyncWaitOperator might be wrong.
> An easy way to fix this might be deep copy the input StreamElement when
> object reuse is enabled, like this:
> https://github.com/apache/flink/blob/blink/flink-streaming-java/src/main/java/org/apache/flink/streaming/api/operators/async/AsyncWaitOperator.java#L209
--
This message was sent by Atlassian Jira
(v8.3.4#803005)