Event partitioning

Using engine_connect or the Apama client library, it is possible to create topologies of correlators across which an application’s monitors can be partitioned. Partitioning is achieved by using the engine_inject tool described in Injecting code into a correlator, or by means of the relevant functions of the client library, to load the relevant monitors directly on to the appropriate correlators.

This scheme is suitable for most applications, as monitors can be loaded once when Apama is brought online. For some applications, however, there is a requirement for a dynamic routing mechanism that (depending on the requirements of the application) continually splits and/or duplicates the incoming event stream and sends it to two or more correlators. This is achieved by using a correlator as a router. A correlator can function as a router upon the injection of EPL that determines which incoming events should be sent to each of the downstream correlators.

The EPL required to make a correlator act as a router, sending events to downstream components which need them but not to others can be very simple as in the following example. This EPL monitor listens for StockTick events and splits them onto two output channels on the basis of each tick’s stock symbol.

event StockTick {
string symbol;
float price;
}

monitor Router {
action onload {
rule1();
rule2();
}
action rule1 {
StockTick st;
on all StockTick(<"M", *):st {
emit st to "chan1";
}
}
action rule2 {
StockTick st;
on all StockTick(>="M", *):st {
emit st to "chan2";
}
}
}

The expectation is that there is a correlator connected to each of the channels. This allows two correlators to process those events in parallel, potentially increasing the throughput of the system as a whole.