Mailing-List: contact dev-help@crunch.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@crunch.apache.org
Date: Thu, 17 Jul 2014 19:15:05 +0000 (UTC)
From: "Micah Whitacre (JIRA)" <jira@apache.org>
To: crunch-dev@incubator.apache.org
Message-ID: <JIRA.12716906.1401224625322.65048.1405624505402@arcas>
In-Reply-To: <JIRA.12716906.1401224625322@arcas>
References: <JIRA.12716906.1401224625322@arcas>
Subject: [jira] [Commented] (CRUNCH-405) Explore adding support for
 idempotent MRPipeline.plan()
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/CRUNCH-405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14065391#comment-14065391 ] 

Micah Whitacre commented on CRUNCH-405:
---------------------------------------

Yeah looks like PCollectionImpl + executor have references to pipeline.  So we could move the logic there.  

{quote}
We might need some sync logic in there to make sure two identical plans weren't executed simultaneously-- there would need to be a way for the execution of one plan to invalidate the execution of any others that were created.
{quote}

The concern here is the following flow:
{code}
//do something
pipeline.runAsync();
//do something 
pipeline.runAsync();
{code}

And the first flow either materializes or writes output that you'd want to make use of during the second async?  Or that the second async doesn't fire off a job that causes the first to fail b/c of output conflict?

> Explore adding support for idempotent MRPipeline.plan()
> -------------------------------------------------------
>
>                 Key: CRUNCH-405
>                 URL: https://issues.apache.org/jira/browse/CRUNCH-405
>             Project: Crunch
>          Issue Type: Improvement
>          Components: Core
>            Reporter: Micah Whitacre
>            Assignee: Micah Whitacre
>         Attachments: CRUNCH-405_v1.patch
>
>
> Talking through a use case with a consumer, they were interested in having the ability to run the MRPipeline.plan() method one to many times prior to ever calling the Pipeline.run/done methods.  The reason for this was they were looking at pulling information off the MRExecutor to tweak settings inside of their DoFns.
> Currently the MRPipeline implementation however does not have an idempotent plan() method as it alters the state of internal values therefore affecting the full run once done() is called.  
> It would be nice if we added an idempotent plan() method that could be gather this information or perhaps a reset option.  


--
This message was sent by Atlassian JIRA
(v6.2#6252)