Light-Weight Queue Trimming Choosing a Quality of Service

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. 20-16 Oracle Complex Event Processing Developers Guide

20.3.2.7 Source Event Identity Externally

Many high availability solutions require that events be correlated between different servers and to do this events need to be universally identifiable. The best way to do this is use external information – preferably a timestamp – to seed the event, rather than relying on the Oracle CEP system to provide this. For more information, see Section 20.3.3.6, Prefer Application Time .

20.3.2.8 Understand the Importance of Event Ordering

For Oracle CEP high availability quality of service options that use queue trimming, not only must primary and secondary servers generate the same output events, but they must also generate them in exactly the same order. Primary and secondary servers must generate the same output events and in exactly the same order when you choose Oracle CEP high availability quality of service options that use queue trimming and equality-based event identify that is, nonmonotonic event identifiers - event identifiers that do not increase continually. In this case, generating output events in different orders can lead to either missed output events or unnecessary duplicate output events when there is a failure Consider the output event streams shown in Figure 20–8 . The primary has output events a, b, and c. After outputting event c, the primary sends the secondary a queue trimming message. Figure 20–8 Event Order The secondary trims all events in its queue generated prior to event c including event c itself. In this case, the set of events trimmed will be {a, b, e, d, c} which is wrong because the primary has not yet output events d and e. If a failover occurs after processing the trimming message for event c, events will be lost. To manage event ordering, consider the following design patterns: ■ Section 20.3.2.8.1, Prefer Deterministic Behavior ■ Section 20.3.2.8.2, Avoid Multithreading ■ Section 20.3.2.8.3, Prefer Monotonic Event Identifiers

20.3.2.8.1 Prefer Deterministic Behavior In order for an application to generate events in

the same order when run on multiple instances, it must be deterministic. The application must not rely on things like: ■ Random number generator that may return different results on different machines. ■ Methods like System.getTimeMillis or System.nanoTime which can return different results on different machines because the system clocks are not synchronized.

20.3.2.8.2 Avoid Multithreading Because thread scheduling algorithms are very timing

dependent, multithreading can be a source of nondeterministic behavior in applications. That is, different threads can be scheduled at different times on different machines.