Under Configuration | Environment Settings | Notification Settings, verify that the Notification Queue Server Name is correct. Do not use "localhost", even if the MSMQ is on the same server as Mariner/Agile.
Notification email for user/data import log contains all old import logs concatenated and not the current import log alone. Import log is not automatically cleaned up and whole import log was sent in each such notification email. Eventually the import log size grows and exceeds the email server size limit for email message, and customer stopped to receive emails with import results.
Verify the Queue is already setup in the Microsoft Message Queue . An example of a Queue path running on the same computer as Mariner might look like this "private$\mariner"
Mail Client process does not clean item cache after each cycle. As a result, each email-submitted item is visible in its initial state for a timeout period of 15/30/60 seconds, depending on cache settings which can cause notifications to not get triggered as expected.
The log excerpt below shows a long delays (40 mins+) in processing of notifications. INFO 12-09-2018 09:43:00 [ Notifications ] -- Notification 'Incident submitted to investigation Queue ' being sent on Tbl:ItemId 1620:1381 for recipient with userid = 96 INFO 12-09-2018 09:43:00 [Notifications] -- Added event 29362915, Tbl:ItemId 1620:1381, to events table for notification 'Incident submitted to investigation Queue' for recipient with userid = 96
Customers might see intermittent instances of orphaned items in the TS_NotificationEvents table proving that events associated with the notification were not cleaned up when the notification was deleted via the admin tool.
SBM isn't cleaning up after itself correctly and leaves a thread id value in the database. Consequently, when JBoss is started next time the notifications with a value in the threadid column is just skipped and don't run again.
