[
https://issues.apache.org/jira/browse/OOZIE-2644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15556539#comment-15556539
]
Robert Kanter commented on OOZIE-2644:
--------------------------------------
It might make sense to generalize this. For instance, we have the
{{eagerVerifyPrecondition}} method in {{XCommand}}, which checks if the
preconditions are met before acquiring the lock to be more efficient. We could
add a submission time check (say {{submissionVerifyPrecondition}} or something)
that gets called when an {{XCommand}} is added to the callablequeue. If it
fails, then we wouldn't even add the {{XCommand}} to the queue. So for these
Notification XCommands, we'd have them check if there's a url set or not.
> Skip queuing Notification Commands when there's nothing to notify
> -----------------------------------------------------------------
>
> Key: OOZIE-2644
> URL: https://issues.apache.org/jira/browse/OOZIE-2644
> Project: Oozie
> Issue Type: Improvement
> Affects Versions: 3.1.3
> Reporter: Robert Kanter
> Assignee: Azrael Seoeun
> Fix For: 5.0.0
>
>
> When you use the
> [Workflow|https://oozie.apache.org/docs/4.2.0/WorkflowFunctionalSpec.html#a5_Workflow_Notifications]
> or
> [Coordinator|https://oozie.apache.org/docs/4.2.0/CoordinatorFunctionalSpec.html#a15._Coordinator_Notifications]
> Notification features, Oozie can end up queuing up a lot of
> {{WorkflowNotificationXCommand}} and {{CoordActionNotificationXCommand}}.
> This happens even if there's no notification configured on the job (which I
> imagine is most of the time); in this case, the {{execute}} method simply
> does nothing. This is wasteful and clogs the queue up.
> We should change the code so that it doesn't queue up one of these Commands
> unless there's actually a URL to notify.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
