[ 
https://issues.apache.org/jira/browse/OOZIE-2534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15298729#comment-15298729
 ] 

Peter Cseh commented on OOZIE-2534:
-----------------------------------

Good idea [~evgenij]!
Your patch adds the jars in the lib folder to the CP even if there is a 
versioned folder present. As far as I know this is not the case for ShareLib.
I would recommend to extract ShareLibService.getLatestLibPath to somewhere and 
use the same logic to choose between folders as in ShareLib. 


> 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 "JA008: File does not exist".
> 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)

Reply via email to