I don't know if this is a bug or if the below scenario was not accounted for when coding the CMSNotificationGateway.RaiseEvent method. If determined NOT to be a bug please feel free to move this to the appropriate forum.

Situation:

I have created a custom notification gateway for a client that allows for notification bundling and digest emails. One feature needed by this client was the ability to notify users when certain files were updated in a media library.

To accomplish this I wrote a task that, in simple terms, checks to see if certain files have been updated and then calls the static CMSNotificationGateway.RaiseEvent method with the appropriate parameters. This task works in a tight loop and multiple RaiseEvent calls (all with different parameters) can be made BEFORE the first call to the custom gateway's SendNotification() method is executed.

Issue:

The issue is that it seems the CMSNotificationGateway.RaiseEvent method gets confused when called multiple times in rapid succession with different parameters. It passes, in an inconsistent manner, the custom gateway object the wrong data for various notifications. The issue is most evident when multiple users are subscribed to the same set of notification events.

For example, if a person is subscribed to 4 update file events (for 4 different files) and the task calls RaiseEvent in quick succession for all 4 the user will get 4 notifications but 2 or more (usually all 4 but not always) will fire for the same SubscriptionID. In other words, the user will get notified 4x about the same file. Sometimes the Resolve data is even missing causing the notification template macros to resolve to empty strings.

Timing:

I have verified this to be a timing issue by I inserting a Thread.Sleep(10000) call in my RaiseEvent loop. This permits the notification thread to complete before the next RaiseEvent call is made. With this in place all the notifications are properly generated.

This, however, is not a solution. The 10 second sleep is arbitrary as I have no idea how long it might take for a single raise event/notification cycle to complete (i.e. it might take 11 seconds to complete). In addition, while RaiseEvent may work on a separate thread (non-blocking) the task does not and I can't have random users waiting up to 40 seconds or longer for any given page to load while the task is "busy waiting".

Thoughts

I would guess that because the RaiseEvent method is static it uses static data which gets overwritten before it can properly execute the gateway Notification() calls when called multiple times in a fast loop. Perhaps a non-static version could be easily created to avoid this issue? Perhaps a re-work of the static version?

Work Around

I'm thinking the only clean way to work around this issue is to break my single task into multiple tasks (one for each file). The Thread.Sleep() method is not viable for the stated reasons. While this would probably work it is inefficient and cumbersome.

My hope is that this issue can be addressed in the next hotfix (if possible). Please let me know any thoughts you might have, what (if anything) can be done and/or if you would like more information.

Thanks!

CMS version : 5.5R2 Build : 5.5.4108
OS version : Microsoft Windows NT 5.2.3790 Service Pack 2
License info : xxxxxxx, Ultimate, 1/1/0001 12:00:00 AM, 05