[
https://issues.apache.org/jira/browse/OOZIE-1783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14000305#comment-14000305
]
Purshotam Shah commented on OOZIE-1783:
---------------------------------------
User can still use new sharelib behavior ( sharelib with timestamps).
I was talking more in terms of HA.
Not only for launchersharelib, even different timestamp of sharelib can be used
by different host.
This is not common scenario, it might happens. One Example, sharelib update
didn't get propagated to one host (bcz of env issue). Each host might submit
job with different sharelib jars for short interval. If purging happens at that
time, then it will purge older sharelib, which is being used and all submitted
will start failing.
If we are not in favor of having different sharelib path for each host, them
somehow we need to have a flag saying that which sharelib is used by each host.
Having a new path in ZK and adding timestamp of sharelib and launcherlib being
used by all host, might help.
> Sharelib purging only occurs at Oozie startup
> ---------------------------------------------
>
> Key: OOZIE-1783
> URL: https://issues.apache.org/jira/browse/OOZIE-1783
> Project: Oozie
> Issue Type: Bug
> Affects Versions: trunk
> Reporter: Robert Kanter
> Assignee: Robert Kanter
> Priority: Critical
> Attachments: OOZIE-1783.patch, OOZIE-1783.patch
>
>
> The purgeLibs method only gets called on startup of the first Oozie server.
> This means that if you update the sharelib without restarting Oozie, then
> Oozie will never clean up the old sharelibs and launcherlibs until you
> restart the server. In fact, with Oozie HA, it will never clean up unless
> you restart all of the servers at the same time (in other words, a rolling
> restart or just restarting one Oozie will never cause purgeLibs to get
> called).
> This should be moved into a background thread (i.e. scheduled with
> SchedulerService) to run periodically. Once a day is probably good enough,
> but we could make it configurable if needed.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
