[ https://issues.apache.org/jira/browse/OOZIE-1118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13611241#comment-13611241 ]
Virag Kothari commented on OOZIE-1118: -------------------------------------- I was thinking of the case where the coordinators are configured to be purged in 3 months while the workflows are configured to be purged in lets say 6 months. Then once the coordinator becomes eligible to purge, the purge service will bring all the workflows of that coordinator in memory every purge interval till 3 months and fail to purge. However, as it a system configuration probably its fine and all this validation may be added later. The patch looks fine to me. One question on the patch: For checking eligibility of purge, all the children are brought into memory. Instead of that, is it better to filter at the db side? E.g Having an sql like {code} select count(*) from child c where c.parent = parent and c is not eligible to purge. if (count > 0) { isEligibleToPurge = false } else { Purge the parent and children } {code} Also, all the queries should bring only selected columns instead of select *. Oozie had run into OOM issues due to select * before. > improve logic of purge service > ------------------------------ > > Key: OOZIE-1118 > URL: https://issues.apache.org/jira/browse/OOZIE-1118 > Project: Oozie > Issue Type: Improvement > Components: bundle, coordinator, workflow > Affects Versions: 3.3.0 > Reporter: Alejandro Abdelnur > Assignee: Robert Kanter > Fix For: trunk > > Attachments: OOZIE-1118.patch, OOZIE-1118.patch, OOZIE-1118.patch, > OOZIE-1118.patch, OOZIE-1118.patch, OOZIE-1118.patch, OOZIE-1118.patch > > > The current logic of the purge service is flat. I.e., WF purging only takes > into account WF end time, it does not take into account that the WF was > started by a COORD job. This means that completed WFs of a running COORD job > could be purge if the COORD job runs for longer that the purge age. > One way of addressing this would be: > * WF purging only purges WF jobs started directly by a client call. > * COORD purging purges COORD jobs started directly by a client call. It also > purges the WF jobs created by the COORD jobs being purged. > * BUNDLE purging purges BUNDLE jobs, and the corresponding COORD jobs and WF > jobs. > This could be handled by a new property in the job beans 'job-owner'. Set to > 'self' it would mean it can be purged by the same job type purger. If set to > other value, then it is a higher level purger the one responsible for purging > it. > This means that for a WF job started by COORD job started by a BUNDLE job, > the WF job and the COORD job would have the BUNDLE job as owner, while the > BUNDLE with have 'self' as owner. > This ownership propagation would also have > A caveat here would be how to handle sub-workflows. > I guess we should check if the wf was created from coord, and if then let > the coord purge take care of that, meaning wf purge does not purge wf started > by coords. > Similarly, the same should also apply for sub-WFs. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira