Understanding monitors and listeners
An introduction to monitors and listeners is in
Description of event processing languages. As mentioned there, monitors are the basic program component that you inject into the correlator. You write monitors in EPL or JMon.
A monitor defines:
One or more listeners — a listener is the EPL mechanism that specifies the event or sequence of events that you are interested in. Conceptually, listeners sift through the streams of events that come in to the correlator and detect matching events.
One or more actions — an action is one or more operations that the correlator performs. An action might be the registration of a listener or it might be the execution of an operation when the correlator finds a match between an incoming event or sequence and a listener.
When the correlator executes an on statement, it creates a listener. A listener watches for an event, or a sequence of events, that matches the event expression specified in the on statement. An event expression defines one or more event templates. Each event template defines an event type to look for, and specifies whether the event's fields should have any specific values. In addition, listeners can specify
Temporal constraints — for example, a listener can specify that two events of interest must be received within 10 minutes.
Logic — for example, a listener can specify that it is interested in event
A or event
B or event
C.
It is often desirable to listen, separately but concurrently, for different instances of the same event type. For example, you might want to listen for and process, separately but concurrently, stock tick events for different stocks. EPL accomplishes this by letting a monitor instance spawn other monitor instances.
In the monitor code, you spawn a monitor instance by specifying the spawn keyword followed by an action. Each act of spawning creates a new instance of the monitor.
When the correlator spawns a monitor instance, it does the following:
1. The correlator creates a new monitor instance from the original monitor instance. The new monitor instance is almost identical to the original. The new monitor instance has a copy of the variables from the original but the active listeners from the original monitor instance are not copied.
2. The correlator invokes the named action on the new monitor instance.
Monitors that contain spawn statements typically act as factories, creating new monitor instances that all listen for the same event type but where each listens for events that have different values in one or more fields. Also, monitors can spawn to particular threads, referred to as contexts in EPL. This enables the correlator to concurrently process multiple monitor instances. (You must create contexts in EPL to implement parallel processing. You can refer to contexts from both EPL and JMon.)
The lifecycle of a monitor is as follows:
1. You use Software AG Designer or a correlator utility to inject the EPL or Java that defines the monitor into the correlator.
2. The correlator creates the original monitor instance, including space for variables as needed.
3. The correlator executes the monitor instance's onload() action.
4. The original monitor instance might spawn several times creating new monitor instances. For each spawned monitor instance, the correlator creates a copy of the original monitor instance's variable space and then executes the specified action.
5. A monitor instance terminates when it has no active listeners. Upon termination, the correlator invokes the monitor instance's ondie() method, if one is defined. Note that it is possible for a monitor instance to remain active after the monitor instance that spawned it has terminated.
6. When the last instance of a particular monitor terminates, the correlator calls the monitor's onunload() method, if it defines one. The last monitor instance to terminate might be the original monitor instance or a spawned monitor instance. Regardless, when the last instance terminates the correlator invokes the monitor's ondie() method and then the monitor's onunload() method, if these methods are defined.
For example, suppose that a monitor definition specifies an ondie() method and an onunload() method. You inject this monitor and the correlator creates the original monitor instance. The original monitor instance spawns 9 times. Consequently, there are 10 instances of that monitor in the correlator. After all of these monitor instances have terminated, the correlator will have called ondie() 10 times and it will have called onunload() once.
