Return-Path: X-Original-To: apmail-reef-dev-archive@minotaur.apache.org Delivered-To: apmail-reef-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 95BCC1948C for ; Fri, 8 Apr 2016 18:29:09 +0000 (UTC) Received: (qmail 87781 invoked by uid 500); 8 Apr 2016 18:29:09 -0000 Delivered-To: apmail-reef-dev-archive@reef.apache.org Received: (qmail 87750 invoked by uid 500); 8 Apr 2016 18:29:09 -0000 Mailing-List: contact dev-help@reef.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@reef.apache.org Delivered-To: mailing list dev@reef.apache.org Received: (qmail 87737 invoked by uid 99); 8 Apr 2016 18:29:08 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 08 Apr 2016 18:29:08 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd2-us-west.apache.org (ASF Mail Server at spamd2-us-west.apache.org) with ESMTP id 838A21A03AA for ; Fri, 8 Apr 2016 18:29:08 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 3.879 X-Spam-Level: *** X-Spam-Status: No, score=3.879 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=2, RCVD_IN_BL_SPAMCOP_NET=2, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd2-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx2-lw-us.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id c9egycweGahf for ; Fri, 8 Apr 2016 18:29:06 +0000 (UTC) Received: from mail-yw0-f182.google.com (mail-yw0-f182.google.com [209.85.161.182]) by mx2-lw-us.apache.org (ASF Mail Server at mx2-lw-us.apache.org) with ESMTPS id 3BA965F1BE for ; Fri, 8 Apr 2016 18:29:06 +0000 (UTC) Received: by mail-yw0-f182.google.com with SMTP id i84so138361761ywc.2 for ; Fri, 08 Apr 2016 11:29:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to; bh=leIcsLM/st6CVBO1XYqpZqn5t5EIvmhcWnTqUTOTCNg=; b=EUT4DfSXFKdsM36E7HkyIavbVeFTRLC/ugYcpPamQXVAKTyXJZEeobtKKjMDyQo0vD o3prremzSHgTOFEODjXvRQDsAhbd87biLSw1YEaW2q6QtW9qpUZLdrAbzBujOQ8wrkLK rF2G4fb7UMTJ7bEhJiivGYoE65KFhGIrwwjEVc9q0a4G3n6CLgg5yeYTJ+OisaznvIbS /8QiZUxUbP6aIWSw4d2msJFgF607PSY8s+XHEXfmhsOCW8R6w0OJHMXAQiw1DBR9eo4s cf3jEHARobwovDDzJUjkkTtXekykzqApY2fzJCMMZnE9TVHeUWxIObucxEQKF3Rr7sYe cfNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to; bh=leIcsLM/st6CVBO1XYqpZqn5t5EIvmhcWnTqUTOTCNg=; b=LVxhA8Is0JYc2T22DulmaFge5Y1fjzVW+1jCu7TTNBXhUaWw/nvN2aD4UnXupEbtUu neunyEjVsPsA4JSb3ljDXaz6/6W6ldyRWRKCAimFdJdrwvrrdQ54YwB2m13KQkN2wdTc XlWHTJHKqJ6fU8QZVJ7YI70gen6PwC0/n3ZnloZLxMsD15G5n4wuudMd4z1jnal6hiMP 1EkOvrfUxmFIoRigyoETG3MrZVDNrLJJ9a6DxrQWSy8Qof8EqjzcbQrbg6QkrvEZlPIf 2IE8rMvXEl0MIg4SNqbgTzwWFQ9Lj7G0f9NT59bmSdsMPV7h3etTDhKvQZu74ItY96qT FFEQ== X-Gm-Message-State: AD7BkJJ81VdbYPxUIRfSJlo3GfBQvKqKptzjI3yJUUCXTulyuOmrEffyQ00T0s279SUIEeyFuQFMp8D+2JC6Pw== MIME-Version: 1.0 X-Received: by 10.37.230.212 with SMTP id d203mr5508178ybh.139.1460140145578; Fri, 08 Apr 2016 11:29:05 -0700 (PDT) Received: by 10.37.208.9 with HTTP; Fri, 8 Apr 2016 11:29:05 -0700 (PDT) In-Reply-To: References: Date: Fri, 8 Apr 2016 11:29:05 -0700 Message-ID: Subject: Re: ICompletedTask semantics From: Dhruv Mahajan To: dev@reef.apache.org Content-Type: multipart/alternative; boundary=94eb2c0a79cab3193c052ffd5e11 --94eb2c0a79cab3193c052ffd5e11 Content-Type: text/plain; charset=UTF-8 I feel if dispose fails, Task should still be termed as completed and failure should be ignored. Can we think of scenarios in which this logic is bad? Dhruv On Fri, Apr 8, 2016 at 11:18 AM, Andrew Chung wrote: > Hi Dhruv, > > Interesting question. There might actually be a race condition here > (somewhat, since I'm not sure if we count the `Dispose` call as part > of the Task), given that `Dispose` is actually called *after* setting > the Task status to `Completed`, and the Task thread locks on a > separate object than the Heartbeat thread. Only the Task status set > operation is atomic. Thus, if the Heartbeat thread gets the Task > status and sends the message to the Driver prior to the Dispose is > called, it is possible that Task.Dispose is not yet called before the > Driver receives the Task completion message. > > Given that we haven't defined a particular order for this sequence of > events, perhaps we should change the behavior to what Dhruv expects? > > Another thing to consider is whether we count `Dispose` as part of the > Task. e.g. If Dispose fails, do we count the Task as failed (Somewhat > dangerous, since many users don't implement Dispose on their Tasks)? > Do we only count the Task as Completed after the Dispose is done? What > do you think? > > Thanks, > Andrew > > On Fri, Apr 8, 2016 at 10:26 AM, Julia Wang (QIUHE) > wrote: > > It has been disposed I believe. > > > > -----Original Message----- > > From: Dhruv Mahajan [mailto:dhruv.mahajan@gmail.com] > > Sent: Friday, April 8, 2016 10:07 AM > > To: dev@reef.apache.org > > Subject: ICompletedTask semantics > > > > Hi > > > > I have a question regarding the semantics of ICompletedTask. Does this > mean that Dispose on the Task has already been called or it will be called > after driver acks. this message? I feel it is former but just wanted to > verify. > > > > Dhruv > --94eb2c0a79cab3193c052ffd5e11--