Quoting experiences may also be a simple sign of getting older.
On Thu, Mar 8, 2012 at 1:00 AM, Mattmann, Chris A (388J) <[email protected]> wrote: > Hey Bruce, > > On Mar 7, 2012, at 5:33 AM, Bruce Barkstrom wrote: > >> This situation appeared in my previous work on an >> archive design at LaRC. The first instance was one >> where I wanted a reasonably secure file transfer - and >> it didn't look like there was an easy way to determine >> if a file transfer had completed so you could start >> checking on the file size. The second instance had >> a Java Messenger Service function that would stash >> the message someplace until there was a request >> to pick it up. The designer apparently couldn't see >> what would happen if the intended recipient object >> disappeared before receiving the message. [This might >> be an interesting failure mode as the system storage >> starts to fill up with undeliverable messages.] > > Two very applicable use cases where this type of > "freeing" of blocked resources comes in handy, that's > for sure. > > Cheers, > Chris > >> >> On Wed, Mar 7, 2012 at 1:26 AM, Mattmann, Chris A (388J) >> <[email protected]> wrote: >>> Hey Bruce, >>> >>> On Mar 6, 2012, at 9:29 AM, Bruce Barkstrom wrote: >>> >>>> This question is a bit like asking the classic ftp software >>>> when has the file finished transferring. The answer seems to me >>>> to be similar to the transaction protocols that produce >>>> reliable ACID behavior. Perhaps it could be one of those >>>> cases that could be handled by carefully crafted exception >>>> handlers: system timed out after [limit], transaction rolled >>>> back with message to log, sender, and receiver. >>> >>> Agree! In pre 0.4 versions of OODT, this was supported by the >>> sense that you could always use the "resumeWorkflowInst" feature >>> to "unpause" a workflow waiting in a condition forever. >>> >>> In 0.4-SNAPSHOT (and the eventual release), workflow conditions now >>> support configurable timeouts, see OODT-215 [1] in general and more >>> specifically OODT- >>> >>> Cheers, >>> Chris >>> >>> [1] https://issues.apache.org/jira/browse/OODT-215 >>> [2] https://issues.apache.org/jira/browse/OODT-207 >>> >>>> >>>> Bruce B. >>>> >>>> On Tue, Mar 6, 2012 at 11:31 AM, Keith Cummings <[email protected]> wrote: >>>>> I have the same question Michael is asking (#1 below). If a precondition >>>>> never passes, I do not want that workflow-task to indefinitely poll on >>>>> that >>>>> precondition. At some point (preferably a configurable amount of time) it >>>>> should give up and fail (halt) the workflow. Or is there another way to >>>>> address this Use Case? >>>>> -Keith Cummings >>>>> >>>>> >>>>> Cayanan, Michael D (388J) wrote: >>>>> >>>>> Hi Chris, >>>>> >>>>> On 3/2/12 9:36 PM, "Mattmann, Chris A (388J)" >>>>> <[email protected]> wrote: >>>>> >>>>> >>>>> >>>>> Hi Mike, >>>>> >>>>> On Mar 2, 2012, at 9:37 AM, Cayanan, Michael D (388J) wrote: >>>>> >>>>> >>>>> >>>>> Hi all, >>>>> >>>>> In the workflow.properties file, I see that I can configure the polling >>>>> time if a pre condition fails via the following property: >>>>> >>>>> org.apache.oodt.cas.workflow.engine.preConditionWaitTime >>>>> >>>>> I have a few questions: >>>>> >>>>> 1) Is this polling infinite? >>>>> >>>>> >>>>> What do you mean by "infinite"? >>>>> >>>>> >>>>> >>>>> If so, would you have to shut the workflow server down in order to stop >>>>> this infinite polling? Or can you shut it down via the workflow manager >>>>> client tool? >>>>> >>>>> >>>>> I'm not sure I follow you? The workflow manager's >>>>> ThreadPoolWorkflowEngine needs to evaluate preconditions, on a per >>>>> workflow-instance basis. >>>>> The only way to shut that down, is to shut down the workflow engine, and >>>>> thus implicitly the WM. >>>>> >>>>> >>>>> In other words, if the pre condition continually fails, will the workflow >>>>> ever timeout where the engine shuts down automatically? >>>>> >>>>> >>>>> >>>>> >>>>> 2) Is there a way to configure the pre condition wait time through the >>>>> PGE config file? For example, if I have 2 PGEs where I want each PGE to >>>>> have different pre condition wait times, is this possible? >>>>> >>>>> >>>>> Can you tell me a specific use case or reason that you would want to have >>>>> different condition check times per PGE? >>>>> >>>>> In short, this can be supported by extending the >>>>> ThreadPoolWorkflowEngine, and then overriding or mapping the condition >>>>> wait >>>>> time to whatever is configured for the PGE. I'd severely caution against >>>>> doing so, b/c you're really giving the developer or >>>>> workflow person an overt amount of control over an aspect of the system >>>>> that will affect (perceived) performance. >>>>> >>>>> >>>>> This was more of a curiosity question than anything. Personally, I don't >>>>> see the need to have a configurable pre condition wait time. In SMAP >>>>> world, there will be a case where a workflow requires two inputs, where >>>>> the inputs are coming from the outputs of 2 different workflows. >>>>> Furthermore, 1 of these inputs isn't expected to arrive like 10 hours >>>>> later after the first input arrives. The assumption here is that 1 input >>>>> will trigger the workflow and thus the pre condition would be to check for >>>>> the existence for that other input. So, if you have your precondition wait >>>>> time to some small interval like 30 seconds, would system performance be >>>>> affected in this case knowing that the precondition isn't expected to be >>>>> satisfied until 10 hours later? >>>>> >>>>> Hope this makes sense. >>>>> >>>>> Thanks again for your help! >>>>> >>>>> -Mike >>>>> >>>>> >>>>> >>>>> Cheers, >>>>> Chris >>>>> >>>>> >>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>>>> Chris Mattmann, Ph.D. >>>>> Senior Computer Scientist >>>>> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA >>>>> Office: 171-266B, Mailstop: 171-246 >>>>> Email: [email protected] >>>>> WWW: http://sunset.usc.edu/~mattmann/ >>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>>>> Adjunct Assistant Professor, Computer Science Department >>>>> University of Southern California, Los Angeles, CA 90089 USA >>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>>>> >>>>> >>>>> >>>>> >>> >>> >>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>> Chris Mattmann, Ph.D. >>> Senior Computer Scientist >>> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA >>> Office: 171-266B, Mailstop: 171-246 >>> Email: [email protected] >>> WWW: http://sunset.usc.edu/~mattmann/ >>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>> Adjunct Assistant Professor, Computer Science Department >>> University of Southern California, Los Angeles, CA 90089 USA >>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>> > > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > Chris Mattmann, Ph.D. > Senior Computer Scientist > NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA > Office: 171-266B, Mailstop: 171-246 > Email: [email protected] > WWW: http://sunset.usc.edu/~mattmann/ > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > Adjunct Assistant Professor, Computer Science Department > University of Southern California, Los Angeles, CA 90089 USA > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >
