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. The correlator can process, concurrently, events in each context.

When you create a context, you can specify whether that context can receive external events. A public context can receive external events, while a private context cannot.

When the correlator enqueues an event the enqueued event goes to a 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.

When the correlator enqueues an event to a particular context the correlator does not place the event on the special enqueued events queue. Instead, the correlator puts the event on the end of the target context’s input queue.

When the correlator routes an event the 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 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: