It's all about the answers!

Ask a question
QuestionsTagsUsersBadges
Guidelines | FAQ
Follow this question
Question details

×42,884
×69

question asked: Oct 20 '15, 6:28 p.m.
question was seen: 2,888 times
last updated: Oct 22 '15, 3:15 a.m.

Related questions

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

0
Joel Lonneker (39●10●16) | asked 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?
Comments
Marek Siekierski commented Oct 20 '15, 6:53 p.m. | edited 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...

Accepted answer

1
permanent link
Lily Wang (4.9k●7●14) | answered 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
Comments
Joel Lonneker commented 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 commented 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 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.