Event processing order for monitors
As mentioned earlier, contexts allow EPL applications to organize work into threads that the correlator can execute concurrently. When you start a correlator it has a main context. You can create additional contexts to enable the correlator to concurrently process events. Each context, including the main context, has its own input queue. The correlator can process, concurrently, events in each context.
Concurrently, in each context, the correlator
Processes events in the order in which they arrive on the context’s input queue
Completely processes one event before it moves on to process the next event
When the correlator processes an event within a given context, it is possible for that processing to:
Send or enqueue an event to a particular channel
The correlator places the event on the input queue of each context that is subscribed to the specified channel.
Send or enqueue an event to a particular context or to a sequence of contexts
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.
Enqueue an event
The correlator places the enqueued event on the special queue just for events generated by the enqueue keyword. A separate thread moves these events to the input queue of each public context. This arrangement ensures that if the input queue of a public context is full, the event generated by enqueue still arrives on its special queue, and is moved to each appropriate input queue as soon as that queue has room. Active event listeners will eventually receive events that are enqueue’d, once those events make their way to the head of the input queue alongside normal events.
Route an event
The correlator places the routed event at the front of that context’s input queue. The correlator processes the routed event before it processes the other events in that input queue.
If the processing of a routed event routes one or more additional events, those additional routed events go to the front of that context’s input queue. The correlator processes them before it processes any events that are already on that context’s input queue.
For example, suppose the correlator is processing the E1 event and events E2, E3, and E4 are on the input queue in that order.
While processing E1, suppose that events En1 and En2 are created in that order and enqueued. These events go to the special queue for enqueued events. Assuming that there is room on the input queue of each public context, the enqueued events go to to the end of the input queue of each public context:
While still processing E1, suppose that events R1 and R2 are created in that order and routed. These events go to the front of the queue:
When the correlator finishes processing E1, it processes R1. While processing R1, suppose that two event listeners trigger and each event listener action routes an event. This puts event R3 and event R4 at the front of that context’s input queue. The input queue now looks like this:
It is important to note that R3 and R4 are on the input queue in front of R2. The correlator processes all routed events, and any events routed from those events, and so on, before it processes the next routed or non-routed event already on the queue.
Now suppose that the correlator is done processing R1 and it begins processing R3. This processing causes R5 to be routed to the front of that context’s input queue. The context’s queue now looks like the following:
