[
https://issues.apache.org/jira/browse/YARN-7676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16299014#comment-16299014
]
Jason Lowe commented on YARN-7676:
----------------------------------
I'm not sure we can fix this in a backwards-compatible way. The Priority class
is simply a priority number with no built-in semantics on the ordering of those
numbers. Two systems decided to implement them differently. It's not
inherently broken since these Priority objects are completely separate, but it
can be confusing.
> Fix inconsistent priority ordering in Priority and SchedulerRequestKey
> ----------------------------------------------------------------------
>
> Key: YARN-7676
> URL: https://issues.apache.org/jira/browse/YARN-7676
> Project: Hadoop YARN
> Issue Type: Bug
> Reporter: Botong Huang
> Assignee: Botong Huang
> Priority: Minor
> Attachments: YARN-7676.v1.patch
>
>
> Today the priority ordering in _Priority.compareTo()_ and
> _SchedulerRequestKey.compareTo()_ is inconsistent. Both _compareTo_ method is
> trying to reverse the order:
> P0.compareTo(P1) > 0, meaning priority wise P0 < P1. However,
> SK(P0).comapreTo(SK(P1)) < 0, meaning priority wise SK(P0) > SK(P1).
> This is attempting to fix that by undo both reversing logic. So that priority
> wise P0 > P1 and SK(P0) > SK(P1).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
