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

Reply via email to