Return-Path: X-Original-To: apmail-crunch-user-archive@www.apache.org Delivered-To: apmail-crunch-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 8C1A2100FF for ; Tue, 1 Apr 2014 19:02:53 +0000 (UTC) Received: (qmail 73682 invoked by uid 500); 1 Apr 2014 19:02:52 -0000 Delivered-To: apmail-crunch-user-archive@crunch.apache.org Received: (qmail 73533 invoked by uid 500); 1 Apr 2014 19:02:48 -0000 Mailing-List: contact user-help@crunch.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@crunch.apache.org Delivered-To: mailing list user@crunch.apache.org Received: (qmail 73522 invoked by uid 99); 1 Apr 2014 19:02:46 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 01 Apr 2014 19:02:46 +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 sjdurfey@gmail.com designates 209.85.214.174 as permitted sender) Received: from [209.85.214.174] (HELO mail-ob0-f174.google.com) (209.85.214.174) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 01 Apr 2014 19:02:40 +0000 Received: by mail-ob0-f174.google.com with SMTP id wo20so11497602obc.19 for ; Tue, 01 Apr 2014 12:02:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:message-id:mime-version:subject:date:references :to:in-reply-to; bh=diNwdPxb//E2kNePQSfeMSy4jRV48douJFGPQZuS8VI=; b=z/9eG+Dw3Rg2/R4Bt3bPzltUCBPIBme01Td9M0TKt5dGzeqPjNCAq0u4YEJaNSq0vl 4DFVjaOr/sDwcdeBGV0Ln64hpxtdaCdaS4Ik5hvQQJJBa+16JbxOLqfbbBFZgRIzw8j8 7AyI4VFYrMU1QIuCc3ly79bxII1hyv5HaTaVAsqroT5iRIMiE2AFkvY/6guE8ArhPsgb qU1hHt56iMI85++oYeAPaUOilC6T+PcanZrzVbBWS+UXnrdLkQg/XKFu7EMY/IKs6aLn uyf0xRh/cEYzmC/BD8uLA7fjNqm6EfpZpVQyJDJAFoLSqT4Y88gs2RcfOtPEhBf02CuT cJuA== X-Received: by 10.60.50.197 with SMTP id e5mr4325819oeo.39.1396378939472; Tue, 01 Apr 2014 12:02:19 -0700 (PDT) Received: from mac-sd023192.cerner.com ([159.140.254.107]) by mx.google.com with ESMTPSA id e8sm78606301oed.7.2014.04.01.12.02.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 01 Apr 2014 12:02:18 -0700 (PDT) From: Stephen Durfey Content-Type: multipart/alternative; boundary="Apple-Mail=_70CB8129-3343-4940-86B4-54A4B7BAF0B8" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: Cleaning up after exceptions Date: Tue, 1 Apr 2014 14:02:19 -0500 References: <6BFA5C59-DF75-4E96-82BF-55D166BA90F7@gmail.com> To: user@crunch.apache.org In-Reply-To: X-Mailer: Apple Mail (2.1874) X-Virus-Checked: Checked by ClamAV on apache.org --Apple-Mail=_70CB8129-3343-4940-86B4-54A4B7BAF0B8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Thanks. I=92ll look into that. Also, I just noticed that as of 0.8.2, = crunch has a public cleanup() on the Pipeline interface. I should be = able to use that, as my code was just updated to that version.=20 On Mar 29, 2014, at 5:58 AM, Josh Wills wrote: > IIRC (I'm away from my computer) we added the ability to add arbitrary = hooks that would always be executed at the end of a pipeline run to the = PipelineExecution interface-- the one that is returned by runAsync), = which could be used to ensure that the temp directories were cleaned up = no matter what happened on the run. Does that work for this problem? >=20 >=20 > On Fri, Mar 28, 2014 at 10:05 AM, Stephen Durfey = wrote: > If I have a scenario where I have already called Pipeline#run (and = some temporary directories were created by Crunch during the run), and = have continued on to do some additional processing (created some new = PCollection=92s and specified a write location), and an exception occurs = in my code, outside of the pipeline, before Pipeline#run is called = again, I would need a way to ensure the temporary directories created in = my initial run are always cleaned up. I could call Pipeline#done, which = calls cleanup() in MRPipeline, but it also calls run(). However, I would = prefer not to have run() called at all, due to the exception thrown in = my code. >=20 > Would it be possible to make cleanup() public in the Pipeline = interface so that can be used to clean up any temp directories created = by the pipeline? >=20 --Apple-Mail=_70CB8129-3343-4940-86B4-54A4B7BAF0B8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Thanks. I=92ll look into that. Also, I just noticed = that as of 0.8.2, crunch has a public cleanup() on the Pipeline = interface. I should be able to use that, as my code was just updated to = that version. 

On Mar 29, 2014, at 5:58 AM, = Josh Wills <josh.wills@gmail.com> = wrote:

IIRC (I'm away from my computer) we added = the ability to add arbitrary hooks that would always be executed at the = end of a pipeline run to the PipelineExecution interface-- the one that = is returned by runAsync), which could be used to ensure that the temp = directories were cleaned up no matter what happened on the run. Does = that work for this problem?


On Fri, = Mar 28, 2014 at 10:05 AM, Stephen Durfey <sjdurfey@gmail.com> wrote:
If I have a scenario = where I have already called Pipeline#run (and some temporary directories = were created by Crunch during the run), and have continued on to do some = additional processing (created some new PCollection=92s and specified a = write location), and an exception occurs in my code, outside of the = pipeline, before Pipeline#run is called again, I would need a way to = ensure the temporary directories created in my initial run are always = cleaned up. I could call Pipeline#done, which calls cleanup() in = MRPipeline, but it also calls run(). However, I would prefer not to have = run() called at all, due to the exception thrown in my code.

Would it be possible to make cleanup() public in the Pipeline interface = so that can be used to clean up any temp directories created by the = pipeline?


= --Apple-Mail=_70CB8129-3343-4940-86B4-54A4B7BAF0B8--