[
https://issues.apache.org/jira/browse/FLINK-11799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Flink Jira Bot updated FLINK-11799:
-----------------------------------
Labels: auto-deprioritized-major auto-unassigned pull-request-available
(was: auto-unassigned pull-request-available stale-major)
Priority: Minor (was: Major)
This issue was labeled "stale-major" 7 ago and has not received any updates so
it is being deprioritized. If this ticket is actually Major, please raise the
priority and ask a committer to assign you the issue or revive the public
discussion.
> 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
> Priority: Minor
> Labels: auto-deprioritized-major, auto-unassigned,
> pull-request-available
> 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)
