[kepler-users] token matching mixup due to unmatched boolean switches

[Colin Enticott]

Hi Tirath,

You could also use the TDA/NimrodK director that does token tagging
and matching. But, as you know, it is a separate download.

Regards,
Colin

2009/10/16 Edward A. Lee <eal at eecs.berkeley.edu>:
>
> The problem here is that you have an implicit notion of time,
> and that notion is absent in PN.
>
> I suggest using the SR director.
>
> Edward
>
>
> Tirath Ramdas wrote:
>>
>> Hi all,
>>
>> I have a situation which I have been able to address in a "kludgy" way,
>> but I wonder if there may be a better way, so I am presenting the problem
>> and my proposed solution here for your critique and counter-suggestions. I
>> am sure it's a situation that many others have encountered. This is with the
>> PN director: I'm not sure how, if at all, the DDF director might help.
>> Anyway, here goes...
>>
>> THE PROBLEM:
>>
>> Let's say I have a single source of data that has to go through 3 actors:
>> A, B, and C. They are laid out in a fork/join configuration. The DataSource
>> goes to A and B, and the outputs from those two actors go to C. In dot
>> notation, this is what my business logic graph looks like:
>>
>> DataSource -> TaskA;
>> DataSource -> TaskB;
>> TaskA -> TaskC;
>> TaskB -> TaskC;
>>
>> This is a trivial workflow. But now, I want to make my TaskA actor more
>> sophisticated and detect failures in the computation (I mean business logic
>> failures - not the kind of thing that can be fixed by re-execution). I will
>> include in TaskA a boolean switch to detect successful jobs and push tokens
>> to the output port only when they are good. But the important thing is that
>> one bad piece of data should not stop the workflow: the rest of the data
>> gets processed as usual.
>>
>> The problem is, TaskB never knows when one of TaskA's jobs fails, and it
>> dutifully pushes all of it's tokens through. As a result, TaskC gets mixed
>> up tokens.
>>
>> A contrived but indicative example: let's say my DataSource is a Ramp
>> producing 1 to 9, TaskB is simply an expression that pushes all tokens
>> through, and TaskA has an "error condition" where a token value "5" is
>> considered an error and routed to the error port instead of the normal
>> output port. Task C just merges both it's inputs into a 2-element array. A
>> sample Kepler workflow is here:http://pastebin.com/m2faecfb3
>>
>> What happens is this:
>>
>> {0, 0}
>> {1, 1}
>> {2, 2}
>> {3, 3}
>> {4, 4}
>> {6, 5} <- problem starts here
>> {7, 6} <-
>> {8, 7} <-
>> {9, 8} <-
>>
>> What I want to see is this:
>>
>> {0, 0}
>> {1, 1}
>> {2, 2}
>> {3, 3}
>> {4, 4}
>> {6, 6} <- desired result
>> {7, 7} <-
>> {8, 8} <-
>> {9, 9} <-
>>
>> MY KLUDGE:
>>
>> I hacked around this simply by passing all of TaskB's results through
>> "passthrough" ports in TaskA, so that TaskA's condition checking can be
>> effectively applied to TaskB's results as well. This is ugly and seriously
>> detracts from the business process flow that I want to express.
>>
>> I don't want to make TaskC responsible for doing TaskB's error checking:
>> what if my TaskC is a very generic actor? In practice TaskB's error-checking
>> is highly application-specific (grep-ing the output of a computational
>> chemistry legacy app).
>>
>> However, I did consider a more generic approach to exception handling that
>> would in fact place the burden on TaskC: I considered the possibility of
>> mandating that every actor must output a record which contains the output
>> data and also a "predication" [1] field. The predication field indicates
>> when the data is valid. Any actor receiving tokens only proceeds with the
>> computation if the predication fields on all it's inputs are set to valid;
>> if even one is invalid, the whole lot gets routed to an error bin, but the
>> next lot gets processed as though nothing went wrong. Also I vaguely recall
>> reading that some other workflow engine does something like this. Anyway, I
>> did not proceed with this yet because it sounds like a non-trivial amount of
>> work to modify all the actors I use to adhere to this behavior.
>>
>> Any other ideas?
>>
>> regards,
>> -tirath
>>
>> [1] Borrowing the word "predication" from Intel's Itanium branch
>> misprediction handling, not sure who they borrowed the term from.
>>
>> _______________________________________________
>> Kepler-users mailing list
>> Kepler-users at kepler-project.org
>> http://mercury.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-users
>
> _______________________________________________
> Kepler-users mailing list
> Kepler-users at kepler-project.org
> http://mercury.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-users
>
>



-- 
Colin