[
https://issues.apache.org/jira/browse/OOZIE-865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Kanter updated OOZIE-865:
--------------------------------
Attachment: workflow.xml
I did some testing with the sample workflow I just attached. It does a fork
where each path goes to a decision and each decision can go to the join node
directly or to an action and then the join node. The validation code blocks
this even though it actually runs correctly.
If you slightly modify the fork in the workflow to go to "path-2-action"
instead of "path-2-decision" (but leaving "path-1-decision" as is), then the
validation code will actually allow this even though there is a decision that
goes directly to the join. But, if you instead modify the fork to go to
"path-1-action" instead of "path-1-decision" (but leave "path-2-decision" as
is), then the validation code will not allow this. So, the ordering of the
fork paths makes a difference, which is probably not a good thing...
It looks like the problem is in LiteWorkflowAppParser.validateFork() where it
checks if the transitions list contains each of the transitions from the
decision node and throws an exception. Perhaps adding a check for "joinNode"
here would fix the problem.
> 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
