[Anthill-pro] AHP3 notification failures with changelog

Jason Dillon jason at planet57.com
Wed Nov 29 15:14:31 CST 2006 

FYI... if one of the notifications mediums in a notification scheme  
fails, it should continue to run the remaining mediums, and then fail  
the notification task.

I have a Yahoo IM medium right after the Email medium which is  
failing.  I'm quite sure that the Yahoo IM would have at least told  
me about the status w/o barfing up about any message being too  
large.  Seems like I need to always Yahoo (or Jabber) first to get  
the quick notification out... though I wonder how AHP3 will handle  
failures if it can't contact the IM server... will that cause Email  
notifications to fail.

Anyways, for notification jobs, it really should take special care to  
try and run all mediums and then report back failures, instead of  
failing on the first.

--jason


On Nov 29, 2006, at 12:43 PM, Jason Dillon wrote:

> I take it back... failure was hidden in one of the log links:
>
> <snip>
> 2835245 INFO  333 - Starting job 333
> 2840167 ERROR 333 - Error sending email: 552 Error: message too large
>
> com.urbancode.command.CommandException: Error sending email: 552  
> Error: message too large
>
> 	at  
> com.urbancode.anthill3.domain.notification.NotificationSchemeWhoWhenSt 
> ep.perform(NotificationSchemeWhoWhenStep.java:93)
> 	at com.urbancode.anthill3.services.jobs.StepExecutor.execute 
> (StepExecutor.java:214)
> 	at com.urbancode.anthill3.services.jobs.StepExecutor.execute 
> (StepExecutor.java:284)
> 	at  
> com.urbancode.anthill3.domain.notification.NotificationSchemeJobDelega 
> te.perform(NotificationSchemeJobDelegate.java:50)
> 	at com.urbancode.anthill3.services.jobs.Job.start(Job.java:117)
> 	at com.urbancode.anthill3.services.jobs.JobService$JobRunner.run 
> (JobService.java:402)
> 	at com.urbancode.commons.util.ThreadPool$WorkerThread.run 
> (ThreadPool.java:155)
> Caused by: com.urbancode.command.CommandException: Error sending  
> email: 552 Error: message too large
>
> 	at  
> com.urbancode.anthill3.command.publishers.emailnotifier.SendEmailComma 
> nd.execute(SendEmailCommand.java:164)
> 	at com.urbancode.anthill3.services.jobs.StepExecutor.execute 
> (StepExecutor.java:496)
> 	at  
> com.urbancode.anthill3.domain.notification.NotificationSchemeWhoWhenSt 
> ep.perform(NotificationSchemeWhoWhenStep.java:88)
> 	... 6 more
> Caused by: com.urbancode.anthill3.AnthillException: Error sending  
> email: 552 Error: message too large
>
> 	at com.urbancode.anthill3.services.email.EmailService.sendEmail 
> (EmailService.java:234)
> 	at  
> com.urbancode.anthill3.command.publishers.emailnotifier.SendEmailComma 
> nd.execute(SendEmailCommand.java:158)
> 	... 8 more
> Caused by: com.sun.mail.smtp.SMTPSendFailedException: 552 Error:  
> message too large
>
> 	at com.sun.mail.smtp.SMTPTransport.issueSendCommand 
> (SMTPTransport.java:1275)
> 	at com.sun.mail.smtp.SMTPTransport.finishData(SMTPTransport.java: 
> 1149)
> 	at com.sun.mail.smtp.SMTPTransport.sendMessage(SMTPTransport.java: 
> 527)
> 	at javax.mail.Transport.send0(Transport.java:151)
> 	at javax.mail.Transport.send(Transport.java:80)
> 	at com.urbancode.anthill3.services.email.EmailService.sendEmail 
> (EmailService.java:227)
> 	... 9 more
> </snip>
>
> That is another point to mention... way to many places to have to  
> go look for logs... and a lot of times the log links return empty  
> pages, so I don't tend to go clicking on all of them to find out  
> what is going on.
>
> Would be nice to have a single consolidated place to find the logs.
>
>  * * *
>
> Okay, so why is this email so large that its getting rejected?
>
> --jason
>
>
> On Nov 29, 2006, at 12:01 PM, Jason Dillon wrote:
>
>> Well, if that was not the problem... then what is?  The logs show  
>> nothing else... and the failure notifications don't ever make it  
>> to my inbox.
>>
>> How can I tell what the real failure was then?
>>
>> --jason
>>
>>
>> On Nov 29, 2006, at 8:30 AM, Eric Minick wrote:
>>
>>> I would assume that this doesn't actually fail the notification,  
>>> it looks like just a warning. The strange thing is that if the  
>>> rest of the header information is intact, Velocity is claiming  
>>> that the getStartDate() method on the header has gone missing or  
>>> is returning null. That's pretty strange.
>>>
>>> You could get rid of the problem by removing the following from  
>>> the snippet.
>>>        <tr>
>>>          <td>Start Date:</td>
>>>          <td>$changeLog.header.startDate</td>
>>>        </tr>
>>>
>>> The obvious place where this would be a bug is if the system was  
>>> not setting the start date. I would expect that we would have hit  
>>> that ourselves internally since we're also on Subversion. Is  
>>> anyone else hitting this kind of problem?
>>>
>>> I'll file it as an issue for now.
>>>
>>> -- Eric
>>>
>>> Jason Dillon wrote:
>>>
>>>> Hi folks, I am still seeing notification failures when a  
>>>> buildlife is  created with a change log.  The notification fails  
>>>> with:
>>>>
>>>> <snip>
>>>> 523170066 WARN  86 0 0 -   
>>>> org.apache.velocity.runtime.exception.ReferenceException:  
>>>> reference :  template = null [line 137,column 15] :  
>>>> $changeLog.header.startDate is  not a valid reference.
>>>> </snip>
>>>>
>>>> The full log for the task is:
>>>>
>>>> <snip>
>>>> 523168083 INFO  86 0 0 -   
>>>> **************************************************************
>>>> 523168083 INFO  86 0 0 - Starting Jakarta Velocity v1.4
>>>> 523168083 INFO  86 0 0 - RuntimeInstance initializing.
>>>> 523168083 INFO  86 0 0 - Default Properties File: org/apache/ 
>>>> velocity/ runtime/defaults/velocity.properties
>>>> 523168083 INFO  86 0 0 - Trying to use logger class   
>>>> org.apache.velocity.runtime.log.SimpleLog4JLogSystem
>>>> 523168083 INFO  86 0 0 - Using logger class   
>>>> org.apache.velocity.runtime.log.SimpleLog4JLogSystem
>>>> 523168084 INFO  86 0 0 - Default ResourceManager initializing.  
>>>> (class  org.apache.velocity.runtime.resource.ResourceManagerImpl)
>>>> 523168084 INFO  86 0 0 - Resource Loader Instantiated:   
>>>> org.apache.velocity.runtime.resource.loader.FileResourceLoader
>>>> 523168084 INFO  86 0 0 - FileResourceLoader : initialization  
>>>> starting.
>>>> 523168084 INFO  86 0 0 - FileResourceLoader : adding path '.'
>>>> 523168084 INFO  86 0 0 - FileResourceLoader : initialization  
>>>> complete.
>>>> 523168084 INFO  86 0 0 - ResourceCache : initialized. (class   
>>>> org.apache.velocity.runtime.resource.ResourceCacheImpl)
>>>> 523168084 INFO  86 0 0 - Default ResourceManager initialization   
>>>> complete.
>>>> 523168085 INFO  86 0 0 - Loaded System Directive:   
>>>> org.apache.velocity.runtime.directive.Literal
>>>> 523168085 INFO  86 0 0 - Loaded System Directive:   
>>>> org.apache.velocity.runtime.directive.Macro
>>>> 523168085 INFO  86 0 0 - Loaded System Directive:   
>>>> org.apache.velocity.runtime.directive.Parse
>>>> 523168085 INFO  86 0 0 - Loaded System Directive:   
>>>> org.apache.velocity.runtime.directive.Include
>>>> 523168085 INFO  86 0 0 - Loaded System Directive:   
>>>> org.apache.velocity.runtime.directive.Foreach
>>>> 523168089 INFO  86 0 0 - Created: 20 parsers.
>>>> 523168089 INFO  86 0 0 - Velocimacro : initialization starting.
>>>> 523168089 INFO  86 0 0 - Velocimacro : allowInline = true : VMs  
>>>> can  be defined inline in templates
>>>> 523168089 INFO  86 0 0 - Velocimacro : allowInlineToOverride =   
>>>> false : VMs defined inline may NOT replace previous VM definitions
>>>> 523168089 INFO  86 0 0 - Velocimacro : allowInlineLocal =  
>>>> false : VMs  defined inline will be  global in scope if allowed.
>>>> 523168089 INFO  86 0 0 - Velocimacro : messages on  : VM system  
>>>> will  output logging messages
>>>> 523168090 INFO  86 0 0 - Velocimacro : autoload off  : VM system  
>>>> will  not automatically reload global library macros
>>>> 523168090 INFO  86 0 0 - Velocimacro : initialization complete.
>>>> 523168090 INFO  86 0 0 - Velocity successfully started.
>>>> 523170066 WARN  86 0 0 -   
>>>> org.apache.velocity.runtime.exception.ReferenceException:  
>>>> reference :  template = null [line 137,column 15] :  
>>>> $changeLog.header.startDate is  not a valid reference.
>>>> </snip>
>>>>
>>>> I get this from the default "Simple Workflow Email Template   
>>>> (changelog)" template that ships with AHP3.
>>>>
>>>> How can I fix this?
>>>>
>>>> --jason
>>>> _______________________________________________
>>>> Anthill-pro mailing list
>>>> Anthill-pro at lists.urbancode.com
>>>> http://lists.urbancode.com/mailman/listinfo/anthill-pro
>>>
>>>
>>> _______________________________________________
>>> Anthill-pro mailing list
>>> Anthill-pro at lists.urbancode.com
>>> http://lists.urbancode.com/mailman/listinfo/anthill-pro
>>
>

More information about the Anthill-pro mailing list