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.
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 an
enqueue statement. The correlator places the event on the input queue of each public context. If the input queue for a public context is full then the correlator keeps the event on a special queue for enqueued events until there is room on the input queue that was full.
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.
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.