[
https://issues.apache.org/jira/browse/MAPREDUCE-5974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14071923#comment-14071923
]
Chris Douglas commented on MAPREDUCE-5974:
------------------------------------------
bq. Implementing this inside the native collector init() method itself might be
messy – you'd have to essentially write a wrapper collector and have every
method delegate to the real implementation. I would hope that the delegation
would get devirtualized and inlined, but not certain about that.
I hadn't considered that; I'm not sure either. I'm mostly ambivalent about the
alternatives, assuming the majority of jobs will configure a single collector.
There's a case to be made for throwing the original exception in that case, but
it's not worth much hand-wringing.
> Allow map output collector fallback
> -----------------------------------
>
> Key: MAPREDUCE-5974
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-5974
> Project: Hadoop Map/Reduce
> Issue Type: Sub-task
> Components: task
> Affects Versions: 2.6.0
> Reporter: Todd Lipcon
> Assignee: Todd Lipcon
> Attachments: mapreduce-5974.txt
>
>
> Currently we only allow specifying a single MapOutputCollector implementation
> class in a job. It would be nice to allow a comma-separated list of classes:
> we should try each collector implementation in the user-specified order until
> we find one that can be successfully instantiated and initted.
> This is useful for cases where a particular optimized collector
> implementation cannot operate on all key/value types, or requires native
> code. The cluster administrator can configure the cluster to try to use the
> optimized collector and fall back to the default collector.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
