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

Peter Bacsko edited comment on OOZIE-3350 at 10/31/18 1:05 PM:
---------------------------------------------------------------

This looks like a valid problem.

It's true that we only store the "topDecisionParent" which is not enough if 
forks are involved.

The solution might not be trivial, because we also have to think about nested 
forks, for example (it's a bit lame ASCII drawing):
{noformat}
              +----------+
              |          |
   +----------+  fork1   +-----+
   |          |          |     |
   |          +----------+     |
   |                           |
   |                           |
+--v--+                 +------v---+
|A    |                 |          |
|     |                 |  fork2   +-------+
+--+--+                 |          |       |
   |                    ++---------+       |
   |                     |                 |
   |                     |                 |
   |                  +--v---+          +--v----+
   |                  |B     |          |D      |
   |                  |      |          |       |
+--v---+              +---+--+          +---+---+
|C     |                  |                 |
|      |                  |                 |
+------+----+             |                 |
            |        +----v--+          +---v---+
            |        |C      |          |E      |
            |        |       |          |       |
            |        +-------+-+      +-+-------+
            |                  |      |
            |                  |      |
            |                +-v------v-+
            |                |          |
            |                |  join2   |
            |                |          |
            |                +------+---+
            |                       |
            |                       |
          +-v----------+            |
          |            +^-----------+
          |  join1     |
          |            |
          |            |
          +------------+
{noformat}

Here, "C" is reachable from two different forks as well. We probably have to 
maintain a {{forkNodes <--> seen nodes}} mapping and we have to make sure that 
every node is available only from a single fork.


was (Author: pbacsko):
This looks like a valid problem.

It's true that we only store the "topDecisionParent" which is not enough if 
forks are involved.

The solution might not be trivial, because we also have to think about nested 
forks, for example (it's a bit lame ASCII drawing):
{noformat}
              +----------+
              |          |
   +----------+  fork1   +-----+
   |          |          |     |
   |          +----------+     |
   |                           |
   |                           |
+--v--+                 +------v---+
|A    |                 |          |
|     |                 |  fork2   +-------+
+--+--+                 |          |       |
   |                    ++---------+       |
   |                     |                 |
   |                     |                 |
   |                  +--v---+          +--v----+
   |                  |B     |          |D      |
   |                  |      |          |       |
+--v---+              +---+--+          +---+---+
|C     |                  |                 |
|      |                  |                 |
+------+----+             |                 |
            |        +----v--+          +---v---+
            |        |C      |          |E      |
            |        |       |          |       |
            |        +-------+-+      +-+-------+
            |                  |      |
            |                  |      |
            |                +-v------v-+
            |                |          |
            |                |  join2   |
            |                |          |
            |                +------+---+
            |                       |
            |                       |
          +-v----------+            |
          |            +^-----------+
          |  join1     |
          |            |
          |            |
          +------------+
{noformat}

Here, "C" is reachable from two different forks as well. We probably have to 
maintain a forkNodes<-->availableNodes mapping and we have to make sure that 
every node is available only from a single fork.

> Forkjoin validation does not fail if a node is reachable from two different 
> forks
> ---------------------------------------------------------------------------------
>
>                 Key: OOZIE-3350
>                 URL: https://issues.apache.org/jira/browse/OOZIE-3350
>             Project: Oozie
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 4.3.1
>            Reporter: wang jinyin
>            Priority: Major
>             Fix For: trunk
>
>   Original Estimate: 120h
>  Remaining Estimate: 120h
>
> when "multiple ok to same node" under decision node, forkjoin validation 
> error.
>  
> such as below example, 'action_C' and 'action_D' both transition to 
> 'action_E'.
> But, because they are under same topDecisionParent 'decision_A', validator 
> will not throw any exception. 
>  
> {quote}<decision name = 'decision_A'>
>     <case to = 'fork_B'></case>
>     <case to = 'action_G'></case>
> </decision>
> <fork name = 'fork_B'>
>     <path start = 'action_C'/>
>     <path start = 'action_D'/>
> </fork>
> <action name = 'action_C'>
>     <ok to = 'action_E'>
>     <error to = 'kill'>
> </action>
> <action name = 'action_D'>
>     <ok to = 'action_E'>
>     <error to = 'kill'>
> </action>
> <action name = 'action_E'>
>     <ok to = 'join_F'>
>     <error to = 'kill'>
> </action>
> <join name = 'join_F'>
>     <ok to = 'action_H'>
>     <error to = 'kill'>
> </join>
> <action name = 'action_G'>
>     <ok to = 'action_H'>
>     <error to = 'kill'>
> </action>
> <action name = 'action_H'>
>     <ok to = 'end'>
>     <error to = 'kill'>
> </action>
> {quote}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to