How do you configure time-to-live on RAM subscription/lifecycle notification email requests?
How do you configure time-to-live on RAM subscription/lifecycle email requests?
We typically prevent sending subscription/lifecycle emails in our dev environment (when doing batch asset uploads) by altering the mail server field in config to a nonsense value.
Recently we re-enabled email by changing the field back to a valid mail server, and we received a blast of lifecycle emails from a bulk asset load we had done 8 days prior.
Our assumptions is that RAM has a retry queue for times when the mail server is not reachable, and that in our dev environment the time-out on this retry queue is greater than 8 days (undesirable). In our prod environment this time-out appears to be less than 24 hours.
How can we configure the timeout of the email retry queue… or the time to live of the email send requests
We have looked in these locations without benefit:
mailMessages.properties in the defaultEmails.jar on tools page
( http://YOURRAMSERVER:13080/ram/admin/repository/tools.faces Customize Emails)
Immediate notification sender schedule on Advanced Configuration page
(http://YOURRAMSERVER:13080/ram/admin/repository/advancedConfiguration.faces Immediate notification sender schedule)
Embedded RTC server setup for email settings
https://YOURRAMSERVER:13443/ramjazz/jts/setup
https://YOURRAMSERVER:13443/ramjazz/admin#action=com.ibm.team.repository.admin.configureMailSettings
Job Schedules on config page (any interaction between these and purging un-serviced email requests?)
Process subscriptions schedule: Every day at 10:00 PM
User/group information update schedule: Every Saturday at 1:00 AM
Review process notifications schedule: Every 1 hours
|
Accepted answer
I am assuming you are on the latest version of RAM (7.5.1.x). In previous versions RAM would throw away the emails if the mail server was down. RAM now re-queues them and tries to send again in anther hour. There is no setting to change the retry interval.
Also keep in mind the subscription job that runs (either every day or at a set time depending on the setting on the Configuration page) will process subscriptions... not lifecycle notifications. The lifecycle notifications are sent immediately (a job kicks off every 30 secs to process these). Each RAM user can set what notifications they want to get on the user preferences page. Refer to this topic in the RAM info center "Modifying user settings" for more information. If you don't want RAM to send any notifications nor you don't want the email to queue up, you could try clearing out the SMTP server field on the RAM configuration page. I think RAM will ignore sending all email... this is not a required field on the RAM configuration page. Just leave it blank. Gordon Flood selected this answer as the correct answer
|
One other answer
|
Thanks, I'll test the behavior out... In particular, we'd like to leave the field "disabled.my.smtp.server" during bulk uploads (rather than nulling it out), and then kill any emails in the retry queue by setting the server null and saving, and then immediately setting back to "my.smtp.server". If this doesn't work, we'll simply null it out to begin with. Similar post under "Disabling temporarily email notification" confirms your advice; failed to find it in my original search. If you don't want RAM to send any notifications nor you don't want the email to queue up, you could try clearing out the SMTP server field on the RAM configuration page. I think RAM will ignore sending all email...
|
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.