[ 
https://issues.apache.org/jira/browse/FLINK-11799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16814188#comment-16814188
 ] 

Ji Liu commented on FLINK-11799:
--------------------------------

Agree, it's necessary to print error log when copy fails and now it dose not 
seems to do this.

> 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)

Reply via email to