[
https://issues.apache.org/jira/browse/OOZIE-2534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15295032#comment-15295032
]
Hadoop QA commented on OOZIE-2534:
----------------------------------
Testing JIRA OOZIE-2534
Cleaning local git workspace
----------------------------
{color:red}-1{color} Patch failed to apply to head of branch
----------------------------
> Versioned action libs (similar to how SharedLibs works)
> -------------------------------------------------------
>
> Key: OOZIE-2534
> URL: https://issues.apache.org/jira/browse/OOZIE-2534
> Project: Oozie
> Issue Type: Improvement
> Components: core
> Affects Versions: 4.2.0
> Reporter: Evgenij Kozhevnikov
> Priority: Trivial
> Attachments: versionedActionLibs.diff
>
>
> Case #1:
> Some projects uses lib folder near the workflow.xml in HDFS to put
> dependencies for the particular module. This jars often contains the version
> in name (example, some-internal-lib-1.2.3.jar). Before update the project you
> have to make sure that there are no RUNNING instances of the workflow,
> otherwise you risk to get an exception "lib not found".
> Case #2:
> There are can be run some separate coordinators in Oozie with common sources
> in HDFS (with different properties). Some projects I've seen have more than
> 30 coordinators with common sources in HDFS. Some of them works daily, some
> hourly and another every 10 minutes. And even more these workflows can be
> called as subworkflows from another sources. It is very difficult to manage
> all this projects during updates. You have to suspend all dependees, make
> sure there are no any running instances and anyway you have to stop your
> cluster activities on this period, so after all the load on the cluster will
> increase.
> Solution:
> I suggest to have the same mechanism as sharedLibs, but for action libs. If
> actionLib contains any jars in the root they will be put on classpath as it
> were before. So the change will be backward compatible. But at the same time
> you can create a subdirectory with prefiix "lib_" and some timestamp or
> incremental version after that. JavaActionExecutor will take only the latest
> version subdirectory and put all artifacts from it to job cache.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
