Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id C2198200B84 for ; Tue, 6 Sep 2016 07:42:22 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id C0930160ACC; Tue, 6 Sep 2016 05:42:22 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 13303160ABC for ; Tue, 6 Sep 2016 07:42:21 +0200 (CEST) Received: (qmail 54631 invoked by uid 500); 6 Sep 2016 05:42:21 -0000 Mailing-List: contact yarn-issues-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list yarn-issues@hadoop.apache.org Received: (qmail 54607 invoked by uid 99); 6 Sep 2016 05:42:21 -0000 Received: from arcas.apache.org (HELO arcas) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 06 Sep 2016 05:42:21 +0000 Received: from arcas.apache.org (localhost [127.0.0.1]) by arcas (Postfix) with ESMTP id F3BD42C1B86 for ; Tue, 6 Sep 2016 05:42:20 +0000 (UTC) Date: Tue, 6 Sep 2016 05:42:20 +0000 (UTC) From: "Sunil G (JIRA)" To: yarn-issues@hadoop.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (YARN-4945) [Umbrella] Capacity Scheduler Preemption Within a queue MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 archived-at: Tue, 06 Sep 2016 05:42:22 -0000 [ https://issues.apache.org/jira/browse/YARN-4945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15466489#comment-15466489 ] Sunil G commented on YARN-4945: ------------------------------- Thanks [~eepayne] bq.LeafQueue#getApplications returns an umnodifiable Collection Yes, I have made changes to handle this scenario. bq.if it's already in selectedCandidates, it's because an inter-queue preemption policy put it there I think I must give some more clarity for what I am trying to do here. Its possible that there can be some containers which were selected by priority/user-limit policy may already be selected from inter-queue policies. In that case, we need not have to mark them again. Rather we can deduct the resource directly as its container marked for preemption. bq.container's resources twice from toObtainByPartition Its a mistake, I corrected the same in second patch. > [Umbrella] Capacity Scheduler Preemption Within a queue > ------------------------------------------------------- > > Key: YARN-4945 > URL: https://issues.apache.org/jira/browse/YARN-4945 > Project: Hadoop YARN > Issue Type: Bug > Reporter: Wangda Tan > Attachments: Intra-Queue Preemption Use Cases.pdf, IntraQueuepreemption-CapacityScheduler (Design).pdf, YARN-2009-wip.2.patch, YARN-2009-wip.patch > > > This is umbrella ticket to track efforts of preemption within a queue to support features like: > YARN-2009. YARN-2113. YARN-4781. -- This message was sent by Atlassian JIRA (v6.3.4#6332) --------------------------------------------------------------------- To unsubscribe, e-mail: yarn-issues-unsubscribe@hadoop.apache.org For additional commands, e-mail: yarn-issues-help@hadoop.apache.org