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

[Edward A. Lee]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: eal.vcf
Type: text/x-vcard
Size: 351 bytes
Desc: not available
URL: <http://lists.nceas.ucsb.edu/kepler/pipermail/kepler-users/attachments/20091015/89a101e7/attachment.vcf>