[
https://issues.apache.org/jira/browse/KYLIN-2857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16162441#comment-16162441
]
zhengdong commented on KYLIN-2857:
----------------------------------
Hi liyang, thanks for your comments.
* Agree. Calling {{Configuration.addResource(new Path(confValue))}} would be
better than parsing XML by ourselves.
* I noted that the Configuration instance only cached in a mapper/reducer and
overwritten parameters in a job config won't affect other jobs.
* For now, {{MRUtil.runMRJob()}} is responsible for overwriting parameters in
kylin_job_conf[_inmem].xml,
and project/cube level parameters is overwritten in
{{AbstractHadoopJob.overrideJobConfig(jobConf, overrides)}}.
How about moving both of them to {{getJobConf()}} and just calling
{{hadoopJob.run(jobArgs)}} to launch a new job.
> MR configuration should be overwritten by user specified parameters when
> resuming MR jobs
> -----------------------------------------------------------------------------------------
>
> Key: KYLIN-2857
> URL: https://issues.apache.org/jira/browse/KYLIN-2857
> Project: Kylin
> Issue Type: Improvement
> Components: Job Engine
> Reporter: zhengdong
> Assignee: Dong Li
> Labels: scope
> Attachments:
> KYLIN-2857-MR-configuration-should-be-overwritten-by.patch
>
>
> For now, MR job conf could be overwritten by kylin_job_conf.xml file, and
> also further overwritten at project/cube level.
> Nonetheless, when resuming a MR job after a job server restarting or other
> kind of interruption, we only use the default conf to trace the job status.
> That's usually not a problem until user hope to overwrite job status tracing
> related parameters (job history server address e.g.) to support multi history
> servers.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)