[
https://issues.apache.org/jira/browse/OOZIE-2129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14359544#comment-14359544
]
Robert Kanter commented on OOZIE-2129:
--------------------------------------
Thanks for the explaination [~shwethags] and [~jaydeepvishwakarma]. Makes
sense: the coord action id should be taken into account.
And while I still think we should try to discourage users from using the Java
action for MR, you are right and a lot of users do that anyway, so I'll relent
on this issue. I wasn't aware of {{Configuration.addDefaultResource}}, but
that sounds like a good solution and should be transparent.
Here's some new comments on the latest patch (v4):
# With {{Configuration.addDefaultResource}}, instead of writing 3 properties to
propagation.xml and then making these load by default, perhaps we should use
{{Configuration.addDefaultResource}} to load the action configuration, which
should already have these 3 configs (and if it doesn't, we should change that).
If it makes sense to change how the action configuration is loaded as a
separate JIRA ([~shwethags] was talking about doing this), then we could make
this JIRA depend on that JIRA. Some additional points on this:
#- Would it make sense to use this for all actions instead of
{{actionConf.addResource}} with the system property?
#- Does this take care of propagating the delegation token too? (i.e. the
{{HADOOP_TOKEN_FILE_LOCATION}} stuff)
#- We should update the Java action documentation. It mentions loading the
config file (and propagating the delegation tokens) which is no longer needed.
Though, in order to prevent confusion, we should probably mention how it used
to be needed but not anymore; instead of simply deleting it.
# I think {{ActionStartXCommand.COORD_ACTION_TAG}} (and "coord.action.tag")
should be called something else. It's not always a coordinator action. How
about "oozie.action.yarn.tag"?
# In {{LauncherMainHadoopUtils}}, you should just print to stdout or stderr
instead of using the {{Logger}}.
# When setting {{mapreduce.job.tags}}, we should append (it's a comma-separated
list of tags) instead of setting it; in case the user set their own tags
# In general, any configuration properties used by Oozie for internal stuff but
put into an MR {{Configuration}} should start with "oozie.". This helps to
namespace these properties as presumably nobody should be starting property
names that way. Please double check that any configs here are starting with
"oozie."
> Duplicate child jobs per instance
> ---------------------------------
>
> Key: OOZIE-2129
> URL: https://issues.apache.org/jira/browse/OOZIE-2129
> Project: Oozie
> Issue Type: Bug
> Reporter: Shwetha G S
> Assignee: Jaydeep Vishwakarma
> Attachments: OOZIE-2129-v0.patch, OOZIE-2129-v1.patch,
> OOZIE-2129-v2.patch, OOZIE-2129-v3.patch, OOZIE-2129-v4.patch
>
>
> OOZIE-1722 ensures that child job is killed at launcher restart. But this
> doesn't work for java actions as the tag is not passed to the child job.
> In case of coord action rerun, new workflow is created and hence new tag. So,
> it doesn't ensure old child job is killed at launcher start
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
