[
https://issues.apache.org/jira/browse/OOZIE-865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13413099#comment-13413099
]
Virag Kothari commented on OOZIE-865:
-------------------------------------
Yes, I agree. Ordering of the nodes should not make a difference and thats a bug
But should the decision node directly be allowed to evaluate to join?
For e.g. (simplified version of the attached workflow)
fork-> decision, action1
action1-> join
decision -> action2, join
action2 -> join
join -> action3
Instead of this, shouldn't the decision node be out of fork?
decision -> action3, fork
fork -> (action1, action2)
action1 -> join
action2 -> join
join ->action3
The above looks cleaner and better design to me
Basically, if the decision goes to join directly, then what is the use of
having the decision node within fork itself?
> ForkJoin validator checks total lengths of forks vs. joins instead of actual
> paths
> ----------------------------------------------------------------------------------
>
> Key: OOZIE-865
> URL: https://issues.apache.org/jira/browse/OOZIE-865
> Project: Oozie
> Issue Type: Bug
> Affects Versions: 3.2.0
> Reporter: Harsh J
> Attachments: workflow.xml
>
>
> Consider a WF that has four fork paths, each to a decision node, and each of
> these eventually in their further paths end at a single join node (thereby
> resulting in a valid DAG).
> When such a WF is passed to Oozie and fork join validator is enabled, the
> validation fails cause the numForks(4) > numJoins(1). This naive way appears
> to be wrong to compare, and we should ideally only compare true path based
> forks->joins lists, if possible.
> This causes a regression if the fork join validation is left enabled.
> Workaround for such workflows currently is to disable fork join validation
> via {{oozie.validate.ForkJoin}} set to {{false}} at the server.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
