join - Oozie fork kills all actions when one is killed -

i use fork/join in oozie, in order parallel sub-workflow actions. workflow.xml looks this:

<workflow-app name="myname" xmlns="uri:oozie:workflow:0.5" <start to="fork1"/> <kill name="kill">     <message>action failed, error message[${wf:errormessage(wf:lasterrornode())}]</message>     </kill>  <fork name="fork1">     <path start="subworkflow1"/>     <path start="subworkflow2"/> </fork> <join name="completed" to="end"  <action name="subworkflow1">     <sub-workflow>         <app-path>....</app-path>         <propagate-configuration/>         <configuration>             <property>                 <name>....</name>                 <value>....</value>             </property>         </configuration>     </sub-workflow>     <ok to="completed"/>     <error to="completed"/> </action>  <action name="subworkflow2">     <sub-workflow>         <app-path>....</app-path>         <propagate-configuration/>         <configuration>             <property>                 <name>....</name>                 <value>....</value>             </property>         </configuration>     </sub-workflow>     <ok to="completed"/>     <error to="completed"/> </action>  <end name="end"></workflow-app> 

when subworkflow1 killed (failed reason), kills subworkflow2 also. want 2 actions parallel, not dependent.

in workflow, when workflow1 killed, see workflow2 killed, app succeeded (i check on oozie dashboard -> workflows in hue).

in case want subworkflow1 killed, subworkflow2 succeed, , don't care entire app say.

• in case, subworkflow1 takes longer subworkflow2, when checked app when ended, saw although says subworkflow1+2 killed, , app succeeded, happened subworkflow2 finished part , though, killed later (it keeps 'running' until paths of fork finish run). workflow2 finished part , killed because workflow1 killed...

what should make each path it's own status , continue running though other path in same fork killed?

i have run issue also. found way oozie behave how want.

your forked actions can have error-to value equal join name. skip subsequent action in particular forked execution path. then, join's "to" value can send control decision node. decision node should check value of wf:lasterrornode(). if value empty string, continue on processing workflow needed. if value not empty string, error occurred , can send control kill node.

here's example:

<start to="forkme"/> <fork name="forkme">     <path start="action1"/>     <path start="action2"/> </fork> <action name="action1">     ...     <ok to="joinme"/>     <error to="joinme"/> </action> <action name="action1">     ...     <ok to="joinme"/>     <error to="joinme"/> </action> <join name="joinme" to="decisionme"/> <decision name="decisionme">   <switch>      <case to="end">         ${wf:lasterrornode() eq ""}      </case>      <default to="error-mail"/>  </switch> </decision> <action name="error-mail">     ...     <ok to="fail"/>     <error to="fail"/> </action> <kill name="fail">     <message>job failed:         message[${wf:errormessage(wf:lasterrornode())}]     </message> </kill> <end name="end"/>