[
https://issues.apache.org/jira/browse/MAPREDUCE-6515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14971056#comment-14971056
]
Jason Lowe commented on MAPREDUCE-6515:
---------------------------------------
Thanks for the patch, Sunil!
I think we should _always_ update the job priority when sent the event.
There's no harm in doing so, and it helps the AM look more consistent to the
client in case the client queries the AM. For example, in the COMMITTING state
the AM is still very much alive and able to respond to client requests -- why
wouldn't we update the priority in that state? We should just treat this like
the diagnostic update transition and always process it.
Actually I'm wondering if we really need to handle this as full-blown event
processing at all. It's a lot of boilerplate, object creation, queueing,
dequeueing, and dispatch just to update an internal reference. The
RMContainerAllocator already has a reference to the Job via getJob(), so we
could just directly call getJob().setPriority rather than all the event
overhead (and risk forgetting to process the event in some state).
RMCommunicator is already doing this to set the queue name, for instance. If
there are locking and concurrency concerns then just make the priority volatile
and use it lock-free since it's read-only once set.
As for the new Job.getPriority method, is it really necessary? The priority is
already available in the JobReport, and it appears the only reason this was
added was to have the JobImpl call it when it was filling out the JobReport.
It can just reference the jobPriority field directly.
As I mentioned in MAPREDUCE-5870 I think the new TypeConverter functions are
too generic. It's dangerous to assume that an int argument will always
intended to be a JobPriority result. I think the name should be
fromYarnPriority or someting like that to make it more clear what's going on
and avoid conflicts with future needs to convert ints into things that aren't a
JobPriority.
Nit: testJobPriorityUpdation s/b testJobPriorityUpdate
> Update Application priority in AM side from AM-RM heartbeat
> -----------------------------------------------------------
>
> Key: MAPREDUCE-6515
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-6515
> Project: Hadoop Map/Reduce
> Issue Type: Bug
> Components: applicationmaster
> Reporter: Sunil G
> Assignee: Sunil G
> Attachments: 0001-MAPREDUCE-6515.patch, 0002-MAPREDUCE-6515.patch
>
>
> After YARN-4170, Application Priority is available via heartbeat call. Update
> this information in AM sothat client can fetch this information via JobStatus
> (JobReport) call.
> This is as per the discussion happened in MAPREDUCE-5870.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
