How to clear email backlog for notifications
Hi,
I have a standalone CLM 5 server. We didn't have an SMTP server access set up, but some users needed to start working so we set them
up. They've now been using it for some time and created a large number of workitems etc.
We now have SMTP access, but when we configure it, it appears CLM is sending out a huge number of backlogged notifications for the past 6
months of activities, resulting in thousands of emails so we've had to remove the SMTP configuration.
We'd like to remove the backlogged notifications, then activate SMTP when the situation is resolved.
Has anyone faced a similar situation? Any help will be appreciated.
- Samar
One answer
The current behavior is the "correct" behavior. 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 change events that are reported will only go back as far as is specified in the advanced settings for the "Scrub Tasks". This is described here.
---
http://www-01.ibm.com/support/docview.wss?uid=swg21390701
com.ibm.team.repository.service.internal.ChangeEventScrubTask
Property:
ChangeEvent Scrub Task Fixed Delay
This property determines the frequency of the change event scrub task. The default is set to 86400 (once per day)
The change event scrub task deletes all change events in the database for more than 14 days (30 days for Work Items, 2 days for build, and so on).
com.ibm.team.repository.service.internal.ChangeEventService
Properties:
ChangeEvent Default Expiration: Default expiration for change events (Default value: 14 days).
ChangeEvent Expiration by Item Type: Override the values specified in Default expiration for a particular type. For example, keep Work Item change events for 30 days, and build change events for 2 days.
ChangeEvent Expiration by Category: Override the values specified in Default expiration for a particular category. For example, keep LDAP nightly sync task events for 2 days, and system log events for 3 days.
Note: Setting the expiration date for a ChangeEvent only affects those ChangeEvents that were created after the setting was changed. This means changing the properties will not purge the already created ChangeEvents faster.
----
Workaround:
The use case here is that you would like to be able to turn off notifications when you perform some task involving many changes. A workaround may be to first set the scrub task frequency to very rapid (1 minute?) and the Work Item Expiration to very small (1 minute).
Now turn off email notification...
perform the task...
wait a minute, then turn on email notification and reset the ChangeEventService and ChangeEventScrubTask values. This will scrub most events prior to the changing the scrub task configuration.
RFE to add the feature to purge the event queue when restarting email notification, for example via a check box enabled on the Email admin page is just created and you may comment there directly and vote for it.
https://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.workitem.viewWorkItem&id=341542
The change events that are reported will only go back as far as is specified in the advanced settings for the "Scrub Tasks". This is described here.
---
http://www-01.ibm.com/support/docview.wss?uid=swg21390701
com.ibm.team.repository.service.internal.ChangeEventScrubTask
Property:
ChangeEvent Scrub Task Fixed Delay
This property determines the frequency of the change event scrub task. The default is set to 86400 (once per day)
The change event scrub task deletes all change events in the database for more than 14 days (30 days for Work Items, 2 days for build, and so on).
com.ibm.team.repository.service.internal.ChangeEventService
Properties:
ChangeEvent Default Expiration: Default expiration for change events (Default value: 14 days).
ChangeEvent Expiration by Item Type: Override the values specified in Default expiration for a particular type. For example, keep Work Item change events for 30 days, and build change events for 2 days.
ChangeEvent Expiration by Category: Override the values specified in Default expiration for a particular category. For example, keep LDAP nightly sync task events for 2 days, and system log events for 3 days.
Note: Setting the expiration date for a ChangeEvent only affects those ChangeEvents that were created after the setting was changed. This means changing the properties will not purge the already created ChangeEvents faster.
----
Workaround:
The use case here is that you would like to be able to turn off notifications when you perform some task involving many changes. A workaround may be to first set the scrub task frequency to very rapid (1 minute?) and the Work Item Expiration to very small (1 minute).
Now turn off email notification...
perform the task...
wait a minute, then turn on email notification and reset the ChangeEventService and ChangeEventScrubTask values. This will scrub most events prior to the changing the scrub task configuration.
RFE to add the feature to purge the event queue when restarting email notification, for example via a check box enabled on the Email admin page is just created and you may comment there directly and vote for it.
https://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.workitem.viewWorkItem&id=341542