[
https://issues.apache.org/jira/browse/FLINK-11799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17323345#comment-17323345
]
Flink Jira Bot commented on FLINK-11799:
----------------------------------------
This issue is assigned but has not received an update in 7 days so it has been
labeled "stale-assigned". If you are still working on the issue, please give an
update and remove the label. If you are no longer working on the issue, please
unassign so someone else may work on it. In 7 days the issue will be
automatically unassigned.
> KryoSerializer/OperatorChain ignores copy failure resulting in
> NullPointerException
> -----------------------------------------------------------------------------------
>
> Key: FLINK-11799
> URL: https://issues.apache.org/jira/browse/FLINK-11799
> Project: Flink
> Issue Type: Bug
> Components: Connectors / Kafka
> Affects Versions: 1.7.2
> Reporter: Jason Kania
> Assignee: Liya Fan
> Priority: Major
> Labels: pull-request-available, stale-assigned
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I was encountering a problem with NullPointerExceptions with the deserialized
> object reaching my ProcessFunction process() method implementation as a null
> value. Upon investigation, I discovered two issues with the implementation of
> the KryoSerializer copy().
> 1) The 'public T copy(T from)' method swallows the error if the kryo copy()
> call generates an exception. The code should report the copy error at least
> once as a warning to be aware that the kryo copy() is failing. I understand
> that the code is there to handle the lack of a copy implementation but due to
> the potential inefficiency of having to write and read the object instead of
> copying it, this would seem useful information to share at the least. It is
> also important to have a warning in case the cause of the copy error is
> something that needs to be fixed.
> 2) The call to 'kryo.readObject(input, from.getClass())' does not handle the
> fact that the kryo readObject(Input input, Class aClass) method may return a
> null value if there are any issues. This could be handled with a check or
> warning in the OperatorChain.CopyingChainingOutput.pushToOperator() method
> but is also ignored there, allowing a null value to be passed along without
> providing any reason for the null value in logging.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
