Return-Path: X-Original-To: apmail-spark-reviews-archive@minotaur.apache.org Delivered-To: apmail-spark-reviews-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id EDA9C1060E for ; Mon, 28 Jul 2014 04:32:04 +0000 (UTC) Received: (qmail 89020 invoked by uid 500); 28 Jul 2014 04:32:04 -0000 Delivered-To: apmail-spark-reviews-archive@spark.apache.org Received: (qmail 88996 invoked by uid 500); 28 Jul 2014 04:32:04 -0000 Mailing-List: contact reviews-help@spark.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: reviews@spark.apache.org Delivered-To: mailing list reviews@spark.apache.org Received: (qmail 88983 invoked by uid 99); 28 Jul 2014 04:32:04 -0000 Received: from tyr.zones.apache.org (HELO tyr.zones.apache.org) (140.211.11.114) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 28 Jul 2014 04:32:04 +0000 Received: by tyr.zones.apache.org (Postfix, from userid 65534) id BD38F9B7343; Mon, 28 Jul 2014 04:32:03 +0000 (UTC) From: CodingCat To: reviews@spark.apache.org Reply-To: reviews@spark.apache.org References: In-Reply-To: Subject: [GitHub] spark pull request: SPARK-2294: fix locality inversion bug in Task... Content-Type: text/plain Message-Id: <20140728043203.BD38F9B7343@tyr.zones.apache.org> Date: Mon, 28 Jul 2014 04:32:03 +0000 (UTC) Github user CodingCat commented on the pull request: https://github.com/apache/spark/pull/1313#issuecomment-50299464 Ah, yes, you're right, working on this... the only issue is that PROCESS_LOCAL is also NODE_LOCAL and myLocalities is not updated upon the completion of each task.... so might not be easy to distinguish if there are some "only NODE_LOCAL" tasks worthing waiting for 3 seconds when we call with NO_PREFS, e.g. case 1: T1 (PROCESS_LOCAL & NODE_LOCAL), T2 (PROCESS_LOCAL & NODE_LOCAL), T3(NO_PREFS) case 2: T1 (PROCESS_LOCAL& NODE_LOCAL), T2(PROCESS_LOCAL& NODE_LOCAL), T3(NODE_LOCAL), T4(NO_PREFS) in case 2, we might need to wait for delay duration when calling with NO_PREFS to prevent T4 being scheduled before T3.... in case 1, we don't need to do that, since all NODE_LOCALS have actually been scheduled --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastructure@apache.org or file a JIRA ticket with INFRA. ---