Event processing order

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, which receives

Events sent to a channel that a monitor in the context is subscribed to. See .

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 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 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 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: