Messaging system

screen1121

We have already described Twproject’s event/subscription capability. Here is describe shortly how this engine works.

When a user subscribes listening an event, say “issue created”, it is creating an object called “listener”.

A listener refers a Twproject object using class and id, has the event it is listening for (called “command”), has a validity period, has a user as owner, may be listening for children object too, etc. .

Usually there are lots of listeners (thousands after some months of real usage).

When something relevant happens, an “event” is generated and inserted in the event queue.

A scheduled job (“EventListenerMatcher”) checks (by default every minute) for each event if there is a subscription listening for. If there is nothing listening, the event is removed.

If there is a subscription a message is generated by integrating “listener” and “event” data; the message is inserted in the message queue. Then the event is removed.

Usually the event queue is empty or contains only a few records.
Once the message is queued it is available for dispatching: “EmailMessageDispatcher” and “StickyMessageDispatcher” are two scheduled jobs that send messages to their respective media channels. Messages for the “news” or “digest” channel rest in the message list until they are read by the user, then removed. So the message queue should contain elements for “news” or “digest” channel only.

Twproject provides list/search and edit pages for subscriptions, events and messages. Usually you do not need to operate in pages that are intended for monitoring purposes only:

screen1122