[
https://issues.apache.org/jira/browse/OOZIE-1835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13995822#comment-13995822
]
Robert Kanter commented on OOZIE-1835:
--------------------------------------
Actually, [~egashira], what should be the correct behavior when the user
doesn't specify the "alert-contact" field? I see later in the code that if we
couldn't parse any to-addresses that it does this:
{code:java}
if (to == null) {
LOG.error("Destination address is null or invalid, stop sending SLA
alert email");
throw new IllegalArgumentException("Destination address is not
specified properly");
}
{code}
If this field is required whenever SLAEmailEventListener is enabled, then all
SLA-enabled jobs/actions have to send out an email with a valid to-address.
What if the user wants most jobs to do JMS but some more important subset of
jobs to also send Emails?
I think it would make sense to make no to-addresses simply log a WARN and only
throw an Exception if there is actually a problem parsing an address; do you
agree?
> NullPointerException from SLAEmailEventListener
> -----------------------------------------------
>
> Key: OOZIE-1835
> URL: https://issues.apache.org/jira/browse/OOZIE-1835
> Project: Oozie
> Issue Type: Bug
> Components: core
> Affects Versions: 4.0.0
> Reporter: Robert Kanter
> Assignee: Robert Kanter
>
> Both the documentation and specification say that the "alert-contact" SLA
> field is optional, at least when you don't want to send email notifications.
> However, if you don't include it, you get a NullPointerException (though it
> doesn't seem to cause any problems):
> {noformat}
> 2014-04-17 22:02:16,664 ERROR
> org.apache.oozie.sla.listener.SLAEmailEventListener:
> SERVER[rkanter-5.ent.cloudera.com] USER[-] GROUP[-] TOKEN[-] APP[-] JOB[-]
> ACTION[-] Failed to send EndMiss alert email
> java.lang.NullPointerException
> at
> org.apache.oozie.sla.listener.SLAEmailEventListener.parseAddress(SLAEmailEventListener.java:231)
> at
> org.apache.oozie.sla.listener.SLAEmailEventListener.setMessageHeader(SLAEmailEventListener.java:262)
> at
> org.apache.oozie.sla.listener.SLAEmailEventListener.sendSLAEmail(SLAEmailEventListener.java:163)
> at
> org.apache.oozie.sla.listener.SLAEmailEventListener.onEndMiss(SLAEmailEventListener.java:200)
> at
> org.apache.oozie.service.EventHandlerService$EventWorker.invokeSLAEventListener(EventHandlerService.java:297)
> at
> org.apache.oozie.service.EventHandlerService$EventWorker.run(EventHandlerService.java:241)
> at
> org.apache.oozie.service.SchedulerService$2.run(SchedulerService.java:174)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:304)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:744)
> {noformat}
> We should give a friendlier WARN message instead.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
