Return-Path: X-Original-To: apmail-hadoop-hdfs-user-archive@minotaur.apache.org Delivered-To: apmail-hadoop-hdfs-user-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 56666E3E2 for ; Tue, 19 Mar 2013 05:54:55 +0000 (UTC) Received: (qmail 76659 invoked by uid 500); 19 Mar 2013 05:54:50 -0000 Delivered-To: apmail-hadoop-hdfs-user-archive@hadoop.apache.org Received: (qmail 76358 invoked by uid 500); 19 Mar 2013 05:54:50 -0000 Mailing-List: contact user-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@hadoop.apache.org Delivered-To: mailing list user@hadoop.apache.org Received: (qmail 76337 invoked by uid 99); 19 Mar 2013 05:54:49 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 19 Mar 2013 05:54:49 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of harsh@cloudera.com designates 209.85.223.175 as permitted sender) Received: from [209.85.223.175] (HELO mail-ie0-f175.google.com) (209.85.223.175) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 19 Mar 2013 05:54:45 +0000 Received: by mail-ie0-f175.google.com with SMTP id c12so128063ieb.6 for ; Mon, 18 Mar 2013 22:54:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:content-type:x-gm-message-state; bh=7Cgmv81zQxmqY4fXd4RhZtttaG8KOX4CoPlnA7uJgtQ=; b=IMKLqpmm+pZvsKV7Vc6fmt0aMFNHxuAuBSQOe+igA/cyqN2jIJdzvzicIDtoIhrf51 BZipMFBrtgNTnFrlQtW+xXDnTQMM+GO4BfZ9OZaE5V/coOTab1sOzIUy9lSwvlO9Yw0C NUdQJ9AbJst/g70KrhTk+lxDhsgWSkYTtjwYL8eL10RM0vvALtLHTZHNKAmxKZDwSsYu JqtRArp88TnxfigfH28XpwfVh8+1pqXQ2JS+J6eghrQSmd7vChFD4b9VguuGi/6T2hi7 Cj8fSBCN4ov9G365vp5rhHRX96wxuqAqZz23lq5Qavyg6XBR+iquCgY4f/sMvqTo4r1f NYmA== X-Received: by 10.50.209.4 with SMTP id mi4mr441193igc.40.1363672464837; Mon, 18 Mar 2013 22:54:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.181.198 with HTTP; Mon, 18 Mar 2013 22:54:04 -0700 (PDT) In-Reply-To: References: From: Harsh J Date: Tue, 19 Mar 2013 11:24:04 +0530 Message-ID: Subject: Re: Question regarding job execution To: "" Content-Type: multipart/alternative; boundary=14dae93404abdbb5ad04d840bcf2 X-Gm-Message-State: ALoCoQm/yjsukjdCZ0oYkS9Sn1KJbjtPLXLI+7NNC0M9QoeJYZ8DdQDMB8jeDz81ZoJZnc4Qt2r5 X-Virus-Checked: Checked by ClamAV on apache.org --14dae93404abdbb5ad04d840bcf2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I am assuming you refer to the YARN's CapacityScheduler. The CS in YARN does support parallel job (the right term is application, or 'app', not 'job' anymore, when speaking in YARN's context) execution. If looking at code of CapacityScheduler.java and LeafQueue.java, you can notice it iterate over all applications for node-update time assignments (see nodeUpdate(=85) call (via NODE_UPDATE event) in former and assignContainers(=85) call in the latter). On Sun, Mar 3, 2013 at 1:28 PM, Jagmohan Chauhan wrote: > Hi > > I am using Capacity scheduler on a cluster of 5 nodes. I submit 3 jobs t= o > the system with a single queue for same user. I am observing that they ar= e > executed on FIFO basis even if the map slots are empty. According to my > observation , when the first job for the user ends then its 2nd job start= s. > > Is it true that when using Capacity Scheduler, for any user, its next job > will be executed when its prior job is finished? > > > > -- > Thanks and Regards > Jagmohan Chauhan > MSc student,CS > Univ. of Saskatchewan > IEEE Graduate Student Member > > http://homepage.usask.ca/~jac735/ > > --=20 Harsh J --14dae93404abdbb5ad04d840bcf2 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
I am assuming you refer to the YARN's CapacitySchedule= r.

The CS in YARN does support parallel job (the right term is = application, or 'app', not 'job' anymore, when speaking in = YARN's context) execution. If looking at code of CapacityScheduler.java= and LeafQueue.java, you can notice it iterate over all applications for no= de-update time assignments (see nodeUpdate(=85) call (via NODE_UPDATE event= ) in former and assignContainers(=85) call in the latter).

On Sun, Mar 3, 2013 at 1:28 PM, Jagmohan Chauhan <simplefundumnni= t@gmail.com> wrote:
Hi

I am using Capac= ity scheduler on a=A0 cluster of 5 nodes. I=20 submit 3 jobs to the system with a single queue for same user. I am=20 observing that they are executed on FIFO basis even if the map slots are empty.=A0 According to my observation , when the first job for the user=20 ends then its 2nd job starts.

Is it true that when using Capacity Scheduler, for any user, its next j= ob will be executed when its prior job is finished?



--
Thanks and Regards
Jagmohan Chauhan=A0
MSc student,CS
Univ. of Saskatchewan=A0
IEEE Graduate=A0Student=A0Member





--
Harsh J
--14dae93404abdbb5ad04d840bcf2--