Event lifecycle
An event enters the correlator in one of the following ways:
An event is received from another component, such as the
engine_send utility, an adapter, another correlator, or a process that is using the Apama client API. The correlator places the event on the input queue of each context that is subscribed to the channel on which the event is sent. If an event is not sent on a named channel then the correlator places the event on the input queue of each public context and each context that is processing a query.
Events sent on the com.apama.queries channel are put on the input queue of each context that is processing a query. These contexts automatically receive events sent on the com.apama.queries channel.
Note:
Apama queries are deprecated and will be removed in a future release.
A correlator pulls an event from a JMS message queue that is set up to distribute events to a cluster of correlators that is processing queries. The correlator adds the event to the input queue of each context that is processing queries.
An EPL program creates an event instance and executes a
send..to statement. If the target is a channel then the correlator places the event on the input queue of each context that is subscribed to that channel. If the target is a context (or a sequence of contexts) then the correlator places the event on the input queue of that context (or on the input queue of each context in the sequence).
An EPL program creates an event instance and executes an
enqueue...to statement. The correlator places the event on the input queue of the specified context or on the input queue of each context in the specified sequence of contexts.
An EPL program creates an event instance and executes a
route statement. The correlator places the event on the input queue of only the context that contains the monitor instance that routed the event.
Monitors
When the event gets to the front of the context's input queue, the correlator evaluates the event to determine if it is a match for any active event listeners in that context. That is, the correlator checks whether there are any event listeners in that context that are watching for that particular event. If there is a match, the match triggers the event listener. This means that the correlator executes the actions defined in the matching event listener.
It is possible for the actions defined in the event listener to route one or more events back to the context's input queue. A routed event goes right to the front of the context input queue. When the correlator is finished processing the event that triggered the event listener action, the correlator evaluates any routed events before it moves on to the event that was on the input queue after the matching event.
Queries
When the event gets to the front of the context's input queue, the correlator extracts the key of the event according to the definitions of running queries that use that event. The window of events for that key value is retrieved from the distributed cache. The correlator adds the event to the retrieved window, which it writes back to the cache. The event pattern of interest is evaluated against the stored window to determine whether the addition of the event causes a match set.
The event remains in its window until the correlator ejects it to make room for a new event or until the query instance or parameterization terminates.