Simple Failover Choosing a Quality of Service

20-14 Oracle Complex Event Processing Developers Guide

20.3.2.3 Only Preserve What You Need

Most Oracle CEP systems are characterized by a large number of raw input events being queried to generate a smaller number of “enriched” events. In general it makes sense to only try and preserve these enriched events – both because there are fewer of them and because they are more valuable.

20.3.2.4 Limit Oracle CEP Application State

Oracle CEP systems allow you to query windows of events. It can be tempting to build systems using very large windows, but this increases the state that needs to be rebuilt when failure occurs. In general it is better to think of long-term state as something better kept in stable storage, such as a distributed cache or a database – since the high availability facilities of these technologies can be appropriately leveraged.

20.3.2.5 Choose an Adequate warm-up-window Time

When a new Oracle CEP server is added to an Oracle CEP high availability multi-server domain or an existing failed server restarts, the server will not have fully joined the Oracle CEP high availability deployment and notification groups until all applications deployed to it have fully joined. The type of application determines when it can be said to have fully joined. Oracle CEP high availability applications can be described as Type 1 or Type 2 applications as Table 20–2 shows. For more information, see Section 20.1.1.3, Rejoining the High Availability Multi-Server Domain .

20.3.2.5.1 Type 1 Applications A Type 1 application requires the new secondary to

generate exactly the same sequence of output events as existing secondaries once it fully joins the Oracle CEP high availability deployment and notification groups. It is a requirement that a Type 1 application be able to rebuild its internal state by processing its input streams for some finite period of time warm-up-window time, after which it generates exactly the same stream of output events as other secondaries running the application. The warm-up-window time is configured on an Oracle CEP high availability output adapter. The warm-up-window time length is specified in terms of seconds or minutes. For example, if the application contains Oracle CQL queries with range-based windows of 5, 7, and 15 minutes then the minimum warm-up-window time is 15 minutes the maximum range-based window size. Oracle recommends that the maximum window length be padded with a few minutes time, as well, to absolutely ensure that the necessary state is available. So, in the previous example 17 minutes or even 20 minutes would be a good length for the warm-up-window time. The Oracle CEP server uses system time during the warm-up-window time period, so it is not directly correlated with the application time associated with events being processed. Table 20–2 Oracle CEP High Availability Application Types Application Type Must generate exactly the same sequence of output events? Must be able to rebuild internal state by processing input streams within a finite period of time? Must wait this period of time before it has fully joined? Type 1 Yes Yes Yes Type 2 No No No Understanding High Availability 20-15 Type 1 applications must only be interested in events that occurred during a finite amount of time. All range-based Oracle CQL windows must be shorter than the warm-up-window time and tuple-based windows must also be qualified by time. For example, the application should only care about the last 10 events if they occurred within the last five minutes. Applications that do not have this property cannot be Type 1 applications and cannot use the warm-up-window period. For example, an application that uses an tuple-based partitioned window that has no time qualification cannot use the warm-up-window period, since an arbitrary amount of time is required to rebuild the state of the window. If a Type 1 application uses the Oracle CEP high availability broadcast output adapter, it may trim events using a unique application-specific key, or a monotonic key like application time. Trimming events using application time is encouraged as it is more robust and less susceptible to bugs in the application that may cause an output event to fail to be generated. For more information, see: ■ Section 20.3.3, Oracle CQL Query Restrictions ■ Section 20.1.3.2, Buffering Output Adapter ■ Section 20.1.3.3, Broadcast Output Adapter ■ Section 20.1.3.4, Correlating Output Adapter

20.3.2.5.2 Type 2 Applications A Type 2 application does not require the new secondary

to generate exactly the same sequence of output events as existing secondaries once it fully joins the Oracle CEP high availability deployment and notification groups. It simply requires that the new cluster member generate valid output events with respect to the point in time at which it begins processing input events. A Type 2 application does not require a warm-up-window period. Most applications will be Type 2 applications. It is common for an application to be brought up at an arbitrary point in time on the primary Oracle CEP server, begin processing events from input streams at that point, and generate valid output events. In other words, the input stream is not paused while the application is started and input events are constantly being generated and arriving. It is reasonable to assume that in many cases a secondary node that does the same thing, but at a slightly different time, will also produce output events that are valid from the point of view of the application, although not necessarily identical to those events produced by the primary because of slight timing differences.For example, a financial application that only runs while the market is open might operate as a Type 2 application as follows: all servers can be brought up before the market opens and will begin processing incoming events at the same point in the market data stream. Multiple secondaries can be run to protect against failure and as long as the number of secondaries is sufficient while the market is open, there is no need to restart any secondaries that fail nor add additional secondaries, so no secondary needs to recover state.

20.3.2.6 Ensure Applications are Idempotent

You should be able to run two copies of an application on different servers and they should not conflict in a shared cache or database. If you are using an external relation such as a cache or table, then you must ensure that when a Oracle CEP server rejoins the cluster, your application is accessing the same cache or table as before: it must be joining against the same external relation again. The data source defined on the server must not have been changed; must ensure youre pulling data from same data source.