[
https://issues.apache.org/jira/browse/FLINK-11799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16814248#comment-16814248
]
Liya Fan commented on FLINK-11799:
----------------------------------
Hi Jason, thanks for opening this issue. For problem 1), I don't think it is a
big problem, although I think some warning should be generated at least. This
is because it only swallows exception of type KryoException, and for this type
of exception, it handles it by reading and serializing the raw data directly.
This should be fine, for data that cannot be copied.
For problem 2), I think it is a good point, because it can be asserted at this
point in the code that the return value should never be null. However, I think
this check should be made by the copy or readObject method.
If you think it is OK, I can take care of this issue :)
> 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
>
> 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
(v7.6.3#76005)
