Jazz Forum Welcome to the Jazz Community Forum Connect and collaborate with IBM Engineering experts and users

RTC 5.0.2 Email Notifications Sending once Enabled though Changes Completed while Disabled.

Questions
Tags
Users
Badges
Joel Lonneker
(39●10●16) Oct 20 '15, 6:28 p.m.
When we need to do bulk work item edits in RTC we disable email in the advanced configuration console, then we wait 15 minutes before starting the CSV imports/updates to these items, finally we wait an additional 15 minutes to enable email again, but users end up getting emails soon as we enable to setting.  This is pretty confusing to users.  My hunch is that the changes get queued up and if the configuration is enabled before the queue is cleared out, then the emails get sent.  

Question:  What do we need to do to ensure users aren't emailed when we disable the email setting, do the work, then enable the email setting?

0 votes

Comments
Marek Siekierski
Oct 20 '15, 6:54 p.m.

Hi Joel,



I don't know of way to guarantee the mail service queue is empty, but enabling the tracing may help. I'll edit this comment if I can find any more info...

1 answer
2,963 views
0 votes

Accepted answer

Permanent link
Lily Wang
(4.9k●7●14) Oct 20 '15, 8:44 p.m.
I had the same issue and got response from that:
The issue was created by the changes for Defect E-mail notifications broken on jazz.net after 5.0 S3 upgrade (306699) The ChangeEventMailNotifier was refactored and now changes made when email is off are now added to the queue when e-mail notification is turned on. It was considered a defect that events would be lost when turning off email for maintenance or when there is a problem with the smtp server. The current behavior is the "correct" behavior.

The only workaround to avoid the email is before enabling mail notification, follow the technote http://www-01.ibm.com/support/docview.wss?uid=swg21390701 scrub the change events in a very short time.
Joel Lonneker selected this answer as the correct answer

1 vote

Comments
Joel Lonneker
Oct 21 '15, 1:04 p.m.

Oh my!
Judging by the technote I should be able configure the following in order to avoid the 30 day queueing that is default for Work Items?

com.ibm.team.repository.service.internal.ChangeEventService:
ChangeEvent Expiration by Category = WorkItem:3600 (1 hour queue)
and
com.ibm.team.repository.service.internal.ChangeEventScrubTask
ChangeEvent Scrub Task Fixed Delay = 3600 (1 hour scrub frequency)

Alternately I could change ChangeEvent Default Expiration from 14 days (1209600 seconds) to 1 hour (3600 seconds) if I didn't care about it queueing anything in general beyond an hour?

Am I understanding that right?

Lily Wang
Oct 22 '15, 3:15 a.m.

Yes, you could change "ChangeEvent Default Expiration" to a even shorter time temporarily. But the bad thing is you need to restart CCM to make the change works.

Your answer

Register or log in to post 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.

Ask a question
Guidelines
FAQ
Search context
Follow this question

By Email: 

Once you sign in you will be able to subscribe for any updates here.

By RSS:

Answers
Answers and Comments
Question details

Question asked: Oct 20 '15, 6:28 p.m.

Question was seen: 2,963 times

Last updated: Oct 22 '15, 3:15 a.m.

Confirmation Cancel Confirm