Hi Pierre
Besides TDCH based use cases we needed something similar for some of our other
use cases and we had to resort to rewriting workflows based on amount of
concurrency we would like to have.
I think it makes a lot of sense to make fork join more configurable in terms of
degree of action
Puru,
I am not sure if 1 and 3 make sense given that your talk on Oozie is
also about the same and it will be a repeat of information.
Robert,
It would be good to talk about the Oozie and unmanaged AM branch work.
Possible for you to do a 5 min talk or get someone else from Cloudera do
Thanks Peter, it worked like a charm!
Regarding the concurrent actions, in my case it seems to be a bit tricky...
I am calling Sqoop actions that are using the Teradata connector. The thing
is that all the oozie launchers for sqoop actions are run concurrently and
there is no more free slots to
Hi Pierre,
Now that you've mentioned it I've found that you can disable fork-join
validation at workflow and application level:
https://oozie.apache.org/docs/4.2.0/WorkflowFunctionalSpec.html#a3.1.5_Fork_and_Join_Control_Nodes
"By default, Oozie performs some validation that any forking in a
Hi Pierre,
There was a bugfix around submitting fork jobs which parallelized job
submission:
https://issues.apache.org/jira/browse/OOZIE-2345
But the issue you've reported is known and not resolved yet:
https://issues.apache.org/jira/browse/OOZIE-1978
I could not find a workaround description,
Hi guys,
I am trying to submit workflows with around 50 actions. However depending
of how the workflow is defined and the number of actions, the time needed
by Oozie to accept the workflow may change a lot (I am not talking about
the execution time of actions, I’m really talking about the time
