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. In a monitor, you can create additional contexts to enable the correlator to concurrently process events.

Note:
In a query, you do not create contexts. Instead, Apama automatically creates contexts as needed to process the incoming events.

Each context, including the main context, has its own input queue, which receives

Events sent specifically to that context from other contexts.

Events sent to a channel that a monitor in the context is subscribed to. See Channels and input events.

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 route an event. A routed event goes to 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 or sent to the context. Assuming that there is room on the input queue of that context, those events go to the end of the input queue of that 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 the 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 that 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: