[
https://issues.apache.org/jira/browse/MAPREDUCE-3516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13176534#comment-13176534
]
Harsh J commented on MAPREDUCE-3516:
------------------------------------
Yes, I guessed so too. The {{.getClass}} stuff we do for type checking will be
the death of 'null' at entry itself.
Otherwise, the serializers are now entirely pluggable and are type agnostic --
they are not limited to just Writables and if I wanted to write a generic
serializer with <Object, Object>, I could as well do that (and nulls may be OK
then, sometimes). This is what I was wondering about -- but given the first
point, I think it is not possible to pass a genuine null at all.
I think it is alright to look for NPEs before the map output buffer runs into
them (while doing those getClass stuff) and show a proper message ("Received
k/v was null" or so?).
> Possible NPE in org.apache.hadoop.mapred.MapTask.MapOutputBuffer.collect(K
> key, V value, int partition)
> -------------------------------------------------------------------------------------------------------
>
> Key: MAPREDUCE-3516
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-3516
> Project: Hadoop Map/Reduce
> Issue Type: Bug
> Components: mrv2
> Affects Versions: 0.20.1, 0.20.2, 0.20.203.0, 0.20.205.0, 0.23.0
> Reporter: Subroto Sanyal
> Assignee: Subroto Sanyal
>
> *org.apache.hadoop.mapred.MapTask.MapOutputBuffer.collect* accepts a pair of
> Key and Value. There is chance that if somehow if a Null value or Key is
> passed to the method, we can end up having NPE.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
