[
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-unassigned pull-request-available stale-major (was:
auto-unassigned pull-request-available)
I am the [Flink Jira Bot|https://github.com/apache/flink-jira-bot/] and I help
the community manage its development. I see this issues has been marked as
Major but is unassigned and neither itself nor its Sub-Tasks have been updated
for 30 days. I have gone ahead and added a "stale-major" to the issue". If this
ticket is a Major, please either assign yourself or give an update. Afterwards,
please remove the label or in 7 days the issue will be deprioritized.
> 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: Major
> Labels: auto-unassigned, pull-request-available, stale-major
> 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)
