24 Developing Applications for High Availability

This chapter introduces Oracle Event Processing components and design patterns that you can use to increase the availability of your Oracle Event Processing applications, along with how to configure high availability for your Oracle Event Processing application to provide the quality of service you require.

This chapter includes the following sections:

24.1 Understanding High Availability

This section introduces Oracle Event Processing components and design patterns that you can use to increase the availability of your Oracle Event Processing applications.

This section includes the following sections:

24.1.1 High Availability Architecture

Like any computing resource, Oracle Event Processing servers can be subject to both hardware and software faults that can lead to data- or service-loss. Oracle Event Processing high availability options seek to mitigate both the likelihood and the impact of such faults.

Oracle Event Processing supports an active-standby high availability architecture. This approach has the advantages of high performance, simplicity, and short failover time.

An Oracle Event Processing application that needs to be highly available is deployed to a group of two or more Oracle Event Processing server instances running in an Oracle Event Processing multi-server domain. Oracle Event Processing will automatically choose one server in the group to be the active primary. The remaining servers become active secondaries.

The primary and secondary servers are all configured to receive the same input events and process them in parallel but only the primary server outputs events to the Oracle Event Processing application client. Depending on the quality of service you choose, the secondary servers buffer their output events using in-memory queues and the primary server keeps the secondary servers up to date with which events the primary has already output.

Figure 24-1 shows a typical configuration.

Figure 24-1 Oracle Event Processing High Availability: Primary and Secondary Servers

Description of Figure 24-1 follows
Description of "Figure 24-1 Oracle Event Processing High Availability: Primary and Secondary Servers"

This section describes:

24.1.1.1 High Availability Lifecycle and Failover

Figure 24-2 shows a state diagram for the Oracle Event Processing high availability lifecycle. In this diagram, the state names (SECONDARY, BECOMING_PRIMARY, and PRIMARY) correspond to the Oracle Event Processing high availability adapter RuntimeMBean method getState return values. These states are specific to Oracle Event Processing.

Figure 24-2 Oracle Event Processing High Availability Lifecycle State Diagram

Description of Figure 24-2 follows
Description of "Figure 24-2 Oracle Event Processing High Availability Lifecycle State Diagram"

It is not possible to specify the server that will be the initial primary. Initially, the first server in the multi-server domain to start up becomes the primary so by starting servers in a particular order, you can influence primary selection. There is no way to force a particular, running server to become the primary. If a primary fails, and then comes back up, it will not automatically become the primary again unless the current primary fails causing a failover.

This section describes the Oracle Event Processing high availability lifecycle in more detail, including:

24.1.1.1.1 Secondary Failure

In general, when a secondary server fails, there is no effect on Oracle Event Processing application operation as Figure 24-3 shows. Regardless of the quality of service you choose, there are no missed or duplicate events.

Figure 24-3 Secondary Failure

Description of Figure 24-3 follows
Description of "Figure 24-3 Secondary Failure"

24.1.1.1.2 Primary Failure and Failover

However, when a primary server fails, as Figure 24-4 shows, Oracle Event Processing performs a failover that may cause missed or duplicate events, depending on the quality of service you choose.

Figure 24-4 Primary Failure and Failover

Description of Figure 24-4 follows
Description of "Figure 24-4 Primary Failure and Failover"

During failover, Oracle Event Processing automatically selects a new primary and the new primary transitions from the SECONDARY state to the BECOMING_PRIMARY state. Depending on the quality of service you choose, the new primary will not transition to PRIMARY state until a configurable readiness threshold is met. For details, see the specific quality of service option in Section 24.1.2, "Choosing a Quality of Service".

24.1.1.1.3 Rejoining the High Availability Multi-Server Domain

When a new Oracle Event Processing server is added to an Oracle Event Processing high availability multi-server domain or an existing failed server restarts, the server will not have fully joined the Oracle Event Processing 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.

If the application must generate exactly the same sequence of output events as existing secondaries (a Type 1 application), then it must be able to rebuild its internal state by processing input streams for some finite period of time (the warm-up-window-length period). This warm-up-window-length time determines the minimum time it will take for the application to fully join the Oracle Event Processing high availability deployment and notification groups.

If the application does not need to generate exactly the same sequence of output events as existing secondaries (a Type 2 application), then it does not require a warm-up-window-length time and will fully join the Oracle Event Processing high availability deployment and notification groups as soon as it is deployed.

For more information, see Section 24.1.3.2.5, "Choose an Adequate warm-up-window-length Time".

24.1.1.2 Deployment Group and Notification Group

All the servers in the multi-server domain belong to the same deployment group: this is the group to which you deploy an application. For the purposes of Oracle Event Processing high availability, you must deploy the same application to all the servers in this group.

By default, all the servers in the multi-server domain also belong to the same notification group. The servers listen to the notification group for membership notifications that indicate when a server has failed (and exited the group) or resumed operation (and rejoined the group), as well as for synchronization notifications from the primary.

If you need to scale your Oracle Event Processing high availability application, you can use the ActiveActiveGroupBean to define a notification group that allows two or more servers to function as a primary server unit while retaining the convenience of a single deployment group that spans all servers (primaries and secondaries).

You must use Oracle Coherence-based clustering to create the multi-server domain deployment group. You may use either default groups or custom groups.

For more information, see:

24.1.1.3 High Availability Components

To implement Oracle Event Processing high availability options, you configure your Event Processing Network (EPN) with a high availability input adapter after each input adapter and a high availability output adapter before each output adapter.

Figure 24-5 shows a typical EPN with all possible high availability adapters in place.

Figure 24-5 High Availability Adapters in the EPN

Description of Figure 24-5 follows
Description of "Figure 24-5 High Availability Adapters in the EPN"

Note:

For simplicity, Figure 24-5 does not show channels and shows only one processor. However, the EPN may be arbitrarily complex with multiple input streams and output streams, channels, multiple processors, event beans, and so on. The only restriction is that each input adapter must be followed by a high availability input adapter and each output adapter must be preceded by a high availability output adapter. Similarly, for simplicity, a multi-server domain of only two Oracle Event Processing servers is shown but you may have an arbitrary number of secondary servers.

The optional high availability input adapter in the primary communicates with the corresponding high availability input adapters in each secondary to normalize event timestamps.

Oracle Event Processing high availability provides one type of high availability input adapter. See Section 24.1.1.3.1, "High Availability Input Adapter".

The high availability output adapter in the primary is responsible for outputting events to the output streams that connect the Oracle Event Processing application to its downstream client. The high availability output adapter in the primary also communicates with the corresponding high availability output adapters in each secondary, and, depending on the high availability quality of service you choose, may instruct the secondary output adapters to trim their in-memory queues of output events.

Oracle Event Processing high availability provides the following high availability output adapters:

Oracle Event Processing high availability also provides a notification groups Spring bean to increase scalability in JMS applications. See Section 24.1.1.3.5, "ActiveActiveGroupBean".

Which adapter you choose is determined by the high availability quality of service you choose. See Section 24.1.2, "Choosing a Quality of Service".

24.1.1.3.1 High Availability Input Adapter

The optional Oracle Event Processing high availability input adapter on the primary Oracle Event Processing server assigns a time (in nanoseconds) to events as they arrive at the adapter and forwards the time values assigned to events to all secondary servers. This ensures that all servers running the application use a consistent time value (and generate the same results) and avoids the need for distributed clock synchronization.

Since a time value is assigned to each event before the event reaches any downstream channels in the EPN, downstream channels should be configured to use application time so that they do not assign a new time value to events as they arrive at the channel.

Input events must have a key that uniquely identifies each event in order to use this adapter.

You can configure the Oracle Event Processing high availability input adapter to send heartbeat events.

The Oracle Event Processing high availability input adapter is applicable to all high availability quality of service options. However, because the high availability input adapter increases performance overhead, it is not appropriate for some high availability quality of service options (such as Section 24.1.2.1, "Simple Failover" and Section 24.1.2.2, "Simple Failover with Buffering"). For these options, you should instead consider using application time with some incoming event property.

For more information, see:

24.1.1.3.2 Buffering Output Adapter

The Oracle Event Processing high availability buffering output adapter implements a buffered queue trimming strategy. The buffer is a sliding window of output events from the stream. The size of the window is measured in milliseconds.

The Oracle Event Processing high availability buffering output adapter is applicable to simple failover and simple failover with buffering high availability quality of service options.

For more information, see:

24.1.1.3.3 Broadcast Output Adapter

The Oracle Event Processing high availability broadcast output adapter implements a distributed queue trimming strategy. The active primary instance broadcasts messages to the active secondary instances in the notification group telling them when to trim their local representation of the queue.

The Oracle Event Processing high availability broadcast output adapter is applicable to the light-weight queue trimming high availability quality of service option.

For more information, see:

24.1.1.3.4 Correlating Output Adapter

The Oracle Event Processing high availability correlating output adapter correlates two event streams, usually from JMS. This adapter correlates an inbound buffer of events with a second source of the same event stream, outputting the buffer if correlation fails after a configurable time interval. Correlated events are trimmed from the queue. Correlated events are assumed to be in-order.

The Oracle Event Processing high availability correlating output adapter is applicable to precise recovery with JMS high availability quality of service option.

For more information, see:

24.1.1.3.5 ActiveActiveGroupBean

The com.oracle.cep.cluster.hagroups.ActiveActiveGroupBean is a Spring bean that allows you to partition an input stream from a JMS input adapter.

This component is applicable to precise recovery with JMS high availability quality of service only. However, it can also be used without high availability to increase Oracle Event Processing application scalability.

For more information, see:

24.1.1.4 High Availability and Scalability

If you need to scale your Oracle Event Processing high availability application, you can use the ActiveActiveGroupBean to define a notification group that allows two or more servers to function as a high availability unit while retaining the convenience of a single deployment group that spans all servers (primaries and secondaries).

Figure 24-6 shows three Oracle Event Processing application scenarios progressing from the simplest configuration, to high availability, and then to both high availability and scalability.

Figure 24-6 High Availability and Scalability

Description of Figure 24-6 follows
Description of "Figure 24-6 High Availability and Scalability"

Most applications begin in a single-server domain without high availability. In this, the simplest scenario, an Oracle Event Processing application running on one Oracle Event Processing server processes an input event stream and produces output events.

In the high availability scenario, the Oracle Event Processing application has been configured to use Oracle Event Processing high availability options. This application is deployed to the deployment group of a multi-server domain composed of two servers. In this scenario, only the primary server outputs events.

In the high availability and scalability scenario, the Oracle Event Processing high availability application has been configured to use the ActiveActiveGroupBean to define notification groups. Each notification group contains two or more Oracle Event Processing servers that function as a single, high availability unit. In this scenario, only the primary server in each notification group outputs events. Should the primary server in a notification group go down, an Oracle Event Processing high availability fail over occurs and a secondary server in that notification group is declared the new primary and resumes outputting events according to the Oracle Event Processing high availability quality of service you configure.

For more information, see:

24.1.1.5 High Availability and Oracle Coherence

Oracle Event Processing high availability options depend on Oracle Coherence. You cannot implement Oracle Event Processing high availability options without Oracle Coherence.

When considering performance tuning, be sure to evaluate your Oracle Coherence configuration in addition to your Oracle Event Processing application.

For more information, see:

24.1.2 Choosing a Quality of Service

Using Oracle Event Processing high availability, you may choose any of the quality of service options that Table 24-1 lists. Choose the quality of service option that suits your application's tolerance for missed and duplicate events as well as expected event throughput. Note that primary and secondary server hardware requirements increase as the quality of service becomes more precise.

Table 24-1 Oracle Event Processing High Availability Quality of Service

High Availability Option Missed Events? Duplicate Events? Performance Overhead

Section 24.1.2.1, "Simple Failover"

Yes (many)

Yes (few)

Negligible

Section 24.1.2.2, "Simple Failover with Buffering"

Yes (few)Foot 1 

Yes (many)

Low

Section 24.1.2.3, "Light-Weight Queue Trimming"

No

Yes (few)

Low-MediumFoot 2 

Section 24.1.2.4, "Precise Recovery with JMS"

No

No

High

Footnote 1 If you configure a big enough buffer then there will be no missed events.

Footnote 2 The performance overhead is tunable. You can adjust the frequency of trimming to reduce the overhead, but incur a higher number of duplicates at failover.

24.1.2.1 Simple Failover

This high availability quality of service is characterized by the lowest performance overhead (fastest recovery time) and the least data integrity (both missed events and duplicate events are possible during failover).

The primary server outputs events and secondary servers simply discard their output events; they do not buffer output events. If the current active primary fails, a new active primary is chosen and begins sending output events once it is notified.

During failover, many events may be missed or duplicated by the new primary depending on whether it is running ahead of or behind the old primary, respectively.

During the failover window, events may be missed. For example, if you are processing 100 events per second and failover takes 10 s then you miss 1000 events

The new primary enters the PRIMARY state immediately. There is no configurable readiness threshold that must be met before the new primary transitions out of the BECOMING_PRIMARY state.

When an Oracle Event Processing server rejoins the multi-server domain, it is immediately available as a secondary.

To implement this high availability quality of service, you configure your EPN with a high availability buffering output adapter (with a sliding window of size zero) before each output adapter. To reduce performance overhead, rather than use a high availability input adapter, use application time with some incoming event property.

For more information, see Section 24.2.1.1, "How to Configure Simple Failover".

24.1.2.2 Simple Failover with Buffering

This high availability quality of service is characterized by a low performance overhead (faster recovery time) and increased data integrity (no missed events but many duplicate events are possible during failover).

The primary server outputs events and secondary servers buffer their output events. If the current active primary fails, a new active primary is chosen and begins sending output events once it is notified.

During the failover window, events may be missed. For example, if you are processing 100 events per second and failover takes 10 s then you miss 1000 events. If the secondary buffers are large, a significant number of duplicates may be output. On the other hand, a larger buffer reduces the chances of missed messages.

When an Oracle Event Processing server rejoins the multi-server domain, if your application is an Oracle Event Processing high availability Type 1 application (the application must generate exactly the same sequence of output events as existing secondaries), it must wait the warm-up-window-length time you configure for the Oracle Event Processing high availability output adapter before it is available as a secondary.

To implement this high availability quality of service, you configure your EPN with a high availability buffering output adapter (with a sliding window of size greater than zero) before each output adapter. To reduce performance overhead, rather than use a high availability input adapter, use application time with some incoming event property.

For more information, see:

24.1.2.3 Light-Weight Queue Trimming

This high availability quality of service is characterized by a low performance overhead (faster recovery time) and increased data integrity (no missed events but a few duplicate events are possible during failover).

The active primary communicates to the secondaries the events that it has actually processed. This enables the secondaries to trim their buffer of output events so that it contains only those events that have not been sent by the primary at a particular point in time. Because events are only trimmed after they have been sent by the current primary, this allows the secondary to avoid missing any output events when there is a failover.

The frequency with which the active primary sends queue trimming messages to active secondaries is configurable:

  • Every n events (n>0)

    This limits the number of duplicate output events to at most n events at failover.

  • Every n milliseconds (n>0)

The queue trimming adapter requires a way to identify events consistently among the active primary and secondaries. The recommended approach is to use application time to identify events, but any key value that uniquely identifies events will do.

The advantage of queue trimming is that output events are never lost. There is a slight performance overhead at the active primary, however, for sending the trimming messages that need to be communicated and this overhead increases as the frequency of queue trimming messages increases.

During failover, the new primary enters the BECOMING_PRIMARY state and will not transition into the PRIMARY state until its event queue (that it was accumulating as a secondary) has been flushed. During this transition, new input events are buffered and some duplicate events may be output.

When an Oracle Event Processing server rejoins the multi-server domain, if your application is an Oracle Event Processing high availability Type 1 application (an application that must generate exactly the same sequence of output events as existing secondaries), it must wait the warm-up-window-length time you configure for the Oracle Event Processing high availability output adapter before it is available as a secondary.

To implement this high availability quality of service, you configure your EPN with a high availability input adapter after each input adapter and a high availability broadcast output adapter before each output adapter.

For more information, see Section 24.2.1.3, "How to Configure Light-Weight Queue Trimming".

24.1.2.4 Precise Recovery with JMS

This high availability quality of service is characterized by a high performance overhead (slower recovery time) and maximum data integrity (no missed events and no duplicate events during failover).

This high availability quality of service is compatible with only JMS input and output adapters.

In this high availability quality of service, we are not concerned with transactional guarantees along the event path for a single-server but in guaranteeing a single output from a set of servers. To achieve this, secondary servers listen, over JMS, to the event stream being published by the primary. As Figure 24-7 shows, this incoming event stream is essentially a source of reliable queue-trimming messages that the secondaries use to trim their output queues. If JMS is configured for reliable delivery we can be sure that the stream of events seen by the secondary is precisely the stream of events output by the primary and thus failover will allow the new primary to output precisely those events not delivered by the old primary.

Figure 24-7 Precise Recovery with JMS

Description of Figure 24-7 follows
Description of "Figure 24-7 Precise Recovery with JMS"

During failover, the new primary enters the BECOMING_PRIMARY state and will not transition into the PRIMARY state its event queue (that it was accumulating as a secondary) has been flushed. During this transition, new input events are buffered and no duplicate events are output.

When an Oracle Event Processing server rejoins the multi-server domain, if your application is an Oracle Event Processing high availability Type 1 application (the application must generate exactly the same sequence of output events as existing secondaries), it must wait the warm-up-window-length time you configure for the Oracle Event Processing high availability output adapter before it is available as a secondary.

To implement this high availability quality of service, you configure your EPN with a high availability input adapter after each input adapter and a high availability correlating output adapter before each output adapter.

To increase scalability, you can also use the cluster groups bean with high availability quality of service.

For more information, see:

24.1.3 Designing an Oracle Event Processing Application for High Availability

Although you can implement Oracle Event Processing high availability declaratively, to fully benefit from the high availability quality of service you choose, you must design your Oracle Event Processing application to take advantage of the high availability options that Oracle Event Processing provides.

When designing your Oracle Event Processing application for high availability, consider the following:

24.1.3.1 Primary Oracle Event Processing High Availability Use Case

You can adapt Oracle Event Processing high availability options to various Oracle Event Processing application designs but in general, Oracle Event Processing high availability is designed for the following use case:

  • An application receives input events from one or more external systems.

  • The external systems are publish-subscribe style systems that allow multiple instances of the application to connect simultaneously and receive the same stream of messages.

  • The application does not update any external systems in a way that would cause conflicts should multiple copies of the application run concurrently.

  • The application sends output events to an external downstream system. Multiple instances of the application can connect to the downstream system simultaneously, although only one instance of the application is allowed to send messages at any one time.

Within these constraints, the following different cases are of interest:

  • The application is allowed to skip sending some output events to the downstream system when there is a failure. Duplicates are also allowed.

    For this case, the following Oracle Event Processing high availability quality of service options are applicable:

  • The application is allowed to send duplicate events to the downstream system, but must not skip any events when there is a failure.

    For this case, the following Oracle Event Processing high availability quality of service options are applicable:

  • The application must send exactly the same stream of messages/events to the downstream system when there is a failure, modulo a brief pause during which events may not be sent when there is a failure.

    For this case, the following Oracle Event Processing high availability quality of service options are applicable

24.1.3.2 High Availability Design Patterns

When designing your Oracle Event Processing application for use with Oracle Event Processing high availability options, observe the following design patterns:

24.1.3.2.1 Select the Minimum High Availability Your Application can Tolerate

Be sure that the extra cost of precise recovery (per-node throughput decrease) is actually necessary for your application.

24.1.3.2.2 Use Oracle Event Processing High Availability Components at All Ingress and Egress Points

You must use an Oracle Event Processing high availability input adapter after each regular input adapter and you must use an Oracle Event Processing high availability output adapter before each regular output adapter.

24.1.3.2.3 Only Preserve What You Need

Most Oracle Event Processing 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.

24.1.3.2.4 Limit Oracle Event Processing Application State

Oracle Event Processing 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.

24.1.3.2.5 Choose an Adequate warm-up-window-length Time

When a new Oracle Event Processing server is added to an Oracle Event Processing high availability multi-server domain or an existing failed server restarts, the server will not have fully joined the Oracle Event Processing 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 Event Processing high availability applications can be described as Type 1 or Type 2 applications as Table 24-2 shows.

Table 24-2 Oracle Event Processing 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

For more information, see Section 24.1.1.1.3, "Rejoining the High Availability Multi-Server Domain".

24.1.3.2.6 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 Event Processing 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-length time), after which it generates exactly the same stream of output events as other secondaries running the application.

The warm-up-window-length time is configured on an Oracle Event Processing high availability output adapter. The warm-up-window-length 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-length 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-length time.

The Oracle Event Processing server uses system time during the warm-up-window-length time period, so it is not directly correlated with the application time associated with events being processed.

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-length 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-length period. For example, an application that uses an tuple-based partitioned window that has no time qualification cannot use the warm-up-window-length period, since an arbitrary amount of time is required to rebuild the state of the window.

If a Type 1 application uses the Oracle Event Processing 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:

24.1.3.2.7 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 Event Processing 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-length 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 Event Processing 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.

24.1.3.2.8 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 Event Processing 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 you're pulling data from same data source.

24.1.3.2.9 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 Event Processing system to provide this.

For more information, see Section 24.1.3.3.6, "Prefer Application Time".

24.1.3.2.10 Understand the Importance of Event Ordering

For Oracle Event Processing 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 Event Processing 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 24-8. The primary has output events a, b, and c. After outputting event c, the primary sends the secondary a queue trimming message.

Figure 24-8 Event Order

Description of Figure 24-8 follows
Description of "Figure 24-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:

24.1.3.2.11 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.

24.1.3.2.12 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.

For example, avoid creating an EPN in which multiple threads send events to an Oracle Event Processing high availability adapter in parallel. If such a channel is an event source for an Oracle Event Processing high availability adapter, it would cause events to be sent to the adapter in parallel by different threads and could make the event order nondeterministic.

For more information on channel configuration to avoid, see:

24.1.3.2.13 Prefer Monotonic Event Identifiers

Event identifiers may be monotonic or nonmontonic.

A monotonic identifier is one that increases continually (such as a time value).

A nonmonotonic identifier does not increase continually and may contain duplicates.

In general, you should design your Oracle Event Processing application using monotonic event identifiers. Using a monotonic event identifier, the Oracle Event Processing high availability adapter can handle an application that may produce events out of order.

24.1.3.2.14 Write Oracle CQL Queries with High Availability in Mind

Not all Oracle CQL query usage is supported when using Oracle Event Processing high availability. You may need to redefine your Oracle CQL queries to address these restrictions.

For more information, see Section 24.1.3.3, "Oracle CQL Query Restrictions".

24.1.3.2.15 Avoid Coupling Servers

The most performant high availability for Oracle Event Processing systems is when servers can run without requiring coordination between them. Generally this can be achieved if there is no shared state and the downstream system can tolerate duplicates. Increasing levels of high availability are targeted at increasing the fidelity of the stream of events that the downstream system sees, but this increasing fidelity comes with a performance penalty.

24.1.3.2.16 Plan for Server Recovery

When a secondary server rejoins the multi-server domain, the server must have time to rebuild the Oracle Event Processing application state to match that of the current primary and active secondaries as Section 24.1.3.2.5, "Choose an Adequate warm-up-window-length Time" describes.

The time it takes for a secondary server to become available as an active secondary after rejoining the multi-server domain will be a factor in the number of active secondaries you require.

If a secondary is declared to be the new primary before it is ready, the secondary will throw an exception.

24.1.3.3 Oracle CQL Query Restrictions

When writing Oracle CQL queries in an Oracle Event Processing application that uses Oracle Event Processing high availability options, observe the following restrictions:

For more information on Oracle CQL, see the Oracle Fusion Middleware CQL Language Reference for Oracle Event Processing.

24.1.3.3.1 Range-Based Windows

In a Type 1 application (where the application must generate exactly the same sequence of output events as existing secondaries), all range-based Oracle CQL windows must be shorter than the warm-up-window-length time. See also Section 24.1.3.2.5, "Choose an Adequate warm-up-window-length Time".

Channels must use application time if Oracle CQL queries contain range-based Windows. See also Section 24.1.3.3.6, "Prefer Application Time".

For more information, see "Range-Based Stream-to-Relation Window Operators" in the Oracle Fusion Middleware CQL Language Reference for Oracle Event Processing.

24.1.3.3.2 Tuple-Based Windows

In a Type 1 application (where the application must generate exactly the same sequence of output events as existing secondaries), all tuple-based windows must also be qualified by time. See also Section 24.1.3.2.5, "Choose an Adequate warm-up-window-length Time".

For more information, see "Tuple-Based Stream-to-Relation Window Operators" in the Oracle Fusion Middleware CQL Language Reference for Oracle Event Processing.

24.1.3.3.3 Partitioned Windows

Consider avoiding partitioned windows: there are cases where a partition cannot be rebuilt. If using partitioned windows, configure a warm-up-window-length time long enough to give the Oracle Event Processing server time to rebuild the partition. See also Section 24.1.3.2.5, "Choose an Adequate warm-up-window-length Time".

For more information, see "Partitioned Stream-to-Relation Window Operators" in the Oracle Fusion Middleware CQL Language Reference for Oracle Event Processing.

24.1.3.3.4 Sliding Windows

Oracle CQL queries should not use sliding windows if new nodes that join the multi-server domain are expected to generate exactly the same output events as existing nodes.

For more information, see:

24.1.3.3.5 DURATION Clause and Non-Event Detection

You must use application time if Oracle CQL queries contain a DURATION clause for non-event detection.

For more information, see:

24.1.3.3.6 Prefer Application Time

In Oracle Event Processing each event is associated with a point in time at which the event occurred. Oracle CQL recognizes two types of time:

  • Application time: a time value assigned to each event outside of Oracle CQL by the application before the event enters the Oracle CQL processor.

  • System time: a time value associated with an event when it arrives at the Oracle CQL processor, essentially by calling System.nanoTime().

Application time is generally the best approach for applications that need to be highly available. The application time is associated with an event before the event is sent to Oracle Event Processing, so it is consistent across active primary and secondary instances. System time, on the other hand, can cause application instances to generate different results since the time value associated with an event can be different on each instance due to system clocks not being synchronized.

You can use system time for applications whose Oracle CQL queries do not use time-based windows. Applications that use only event-based windows depend only on the arrival order of events rather than the arrival time, so you may use system time in this case.

If you must use system time with Oracle CQL queries that do use time-based windows, then you must use a special Oracle Event Processing high availability input adapter that intercepts incoming events and assigns a consistent time that spans primary and secondary instances.

24.2 Configuring High Availability

This section describes how to configure high availability for your Oracle Event Processing application to provide the quality of service you require, including information on configuring failover, recovery and queue trimming, as well as configuring high availability adapters.

This section includes the following sections:

24.2.1 Configuring High Availability Quality of Service

You configure Oracle Event Processing high availability quality of service in the EPN assembly file and component configuration files. For general information about these configuration files, see:

Note:

After making any Oracle Event Processing high availability configuration changes, you must redeploy your Oracle Event Processing application. See Section 23.5, "Deploying Oracle Event Processing Applications".

This section describes:

For more information on configuring an Oracle Event Processing high availability application for scalability, see Chapter 25, "Developing Scalable Applications".

24.2.1.1 How to Configure Simple Failover

You configure simple failover using the Oracle Event Processing buffering output adapter with a sliding window size of zero (0).

This procedure starts with the example EPN that Figure 24-9 shows and adds the required components to configure it for simple failover. Example 24-1 shows the corresponding EPN assembly file and Example 24-2 shows the corresponding component configuration file.

For more information about this Oracle Event Processing high availability quality of service, see Section 24.1.2.1, "Simple Failover".

Figure 24-9 Simple Failover EPN

Description of Figure 24-9 follows
Description of "Figure 24-9 Simple Failover EPN"

Example 24-1 Simple Failover EPN Assembly File

<?xml version="1.0" encoding="UTF-8"?>
<beans ...>

    <wlevs:event-type-repository>
        <wlevs:event-type type-name="HelloWorldEvent">
            <wlevs:class>com.bea.wlevs.event.example.helloworld.HelloWorldEvent</wlevs:class>
        </wlevs:event-type>
    </wlevs:event-type-repository>

    <wlevs:adapter id="helloworldAdapter" 
        class="com.bea.wlevs.adapter.example.helloworld.HelloWorldAdapter" >
        <wlevs:instance-property name="message" value="HelloWorld - the current time is:"/>
    </wlevs:adapter>

    <wlevs:channel id="helloworldInputChannel" event-type="HelloWorldEvent" >
        <wlevs:listener ref="helloworldProcessor"/>
        <wlevs:source ref="helloworldAdapter"/>
    </wlevs:channel>

    <wlevs:processor id="helloworldProcessor" />
    
    <wlevs:channel id="helloworldOutputChannel" event-type="HelloWorldEvent" advertise="true">
        <wlevs:listener>
            <bean class="com.bea.wlevs.example.helloworld.HelloWorldBean"/>
        </wlevs:listener>
        <wlevs:source ref="helloworldProcessor"/>
    </wlevs:channel>

</beans>

Example 24-2 Simple Failover Component Configuration Assembly File

<?xml version="1.0" encoding="UTF-8"?>
<wlevs:config 
        xmlns:wlevs="http://www.bea.com/ns/wlevs/config/application"
        xmlns:ha="http://www.oracle.com/ns/cep/config/cluster/">
    <processor>
        <name>helloworldProcessor</name>
        <rules>
            <query id="helloworldRule">
                <![CDATA[ select * from helloworldInputChannel [Now] ]]>
            </query>
        </rules>
    </processor>
</wlevs:config>

To configure simple failover:

  1. Create a multi-server domain using Oracle Coherence.

    For more information, see:

  2. Create an Oracle Event Processing application.

    For more information, see Section 5.2, "Creating Oracle Event Processing Projects".

  3. Edit the MANIFEST.MF file to add the following Import-Package entries:

    • com.bea.wlevs.ede.api.cluster

    • com.oracle.cep.cluster.hagroups

    • com.oracle.cep.cluster.ha.adapter

    • com.oracle.cep.cluster.ha.api

    For more information, see Section 5.7.2, "How to Add an OSGi Bundle to an Oracle Event Processing Project".

  4. Configure your Oracle Event Processing application EPN assembly file to add an Oracle Event Processing high availability buffering output adapter as Example 24-3 shows.

    • Add a wlevs:adapter element with provider set to ha-buffering after channel helloworldOutputChannel.

    • Update the wlevs:listener element in channel helloworldOutputChannel to reference the ha-buffering adapter by its id.

    • Add a wlevs:listener element to the ha-buffering adapter that references the HelloWorldBean class.

    Example 24-3 Simple Failover EPN Assembly File: Buffering Output Adapter

    <?xml version="1.0" encoding="UTF-8"?>
<beans ...>

    <wlevs:event-type-repository>
        <wlevs:event-type type-name="HelloWorldEvent">
            <wlevs:class>com.bea.wlevs.event.example.helloworld.HelloWorldEvent</wlevs:class>
        </wlevs:event-type>
    </wlevs:event-type-repository>

    <wlevs:adapter id="helloworldAdapter" 
        class="com.bea.wlevs.adapter.example.helloworld.HelloWorldAdapter" >
        <wlevs:instance-property name="message" value="HelloWorld - the current time is:"/>
    </wlevs:adapter>

    <wlevs:channel id="helloworldInputChannel" event-type="HelloWorldEvent" >
        <wlevs:listener ref="helloworldProcessor"/>
    </wlevs:channel>

    <wlevs:processor id="helloworldProcessor" />

    <wlevs:channel id="helloworldOutputChannel" event-type="HelloWorldEvent" advertise="true">
        <wlevs:listener ref="myHaSlidingWindowAdapter"/>
        <wlevs:source ref="helloworldProcessor"/>
    </wlevs:channel>

    <wlevs:adapter id="myHaSlidingWindowAdapter" provider="ha-buffering" >
        <wlevs:listener>
            <bean class="com.bea.wlevs.example.helloworld.HelloWorldBean"/>
        </wlevs:listener>
    </wlevs:adapter>

</beans>

  5. Optionally, configure the channel downstream from the input adapter (helloworldInputChannel) to configure an application timestamp based on an appropriate event property as Example 24-4 shows.

    For simple failover, you can use system timestamps because events are not correlated between servers. However, it is possible that slightly different results might be output from the buffer if application timestamps are not used.

    In this example, event property arrivalTime is used.

    The wlevs:expression should be set to this event property.

    Example 24-4 Application Timestamp Configuration

    ...
    <wlevs:channel id="helloworldInputChannel" event-type="HelloWorldEvent" >
        <wlevs:listener ref="helloworldProcessor"/>
        <wlevs:source ref="myHaInputAdapter"/>
        <wlevs:application-timestamped>
            <wlevs:expression>arrivalTime</wlevs:expression>
        </wlevs:application-timestamped>
    </wlevs:channel>
...

  6. Configure the Oracle Event Processing high availability buffering output adapter.

    Set the instance property windowLength to zero (0) as Example 24-5 shows.

    Example 24-5 Configuring windowLength in the Buffering Output Adapter

    ...
    <wlevs:adapter id="myHaSlidingWindowAdapter" provider="ha-buffering" >
        <wlevs:listener>
            <bean class="com.bea.wlevs.example.helloworld.HelloWorldBean"/>
        </wlevs:listener>
        <wlevs:instance-property name="windowLength" value="0"/>
    </wlevs:adapter>
...

    For more information, see Section 24.2.2.2.1, "Buffering Output Adapter EPN Assembly File Configuration".

  7. Optionally, configure the component configuration file to include the Oracle Event Processing high availability buffering output adapter as Example 24-6 shows.

    Example 24-6 Simple Failover Component Configuration File With High Availability Adapters

    <?xml version="1.0" encoding="UTF-8"?>
<wlevs:config 
        xmlns:wlevs="http://www.bea.com/ns/wlevs/config/application"
        xmlns:ha="http://www.oracle.com/ns/cep/config/cluster/">
    <processor>
        <name>helloworldProcessor</name>
        <rules>
            <query id="helloworldRule">
                <![CDATA[ select * from helloworldInputChannel [Now] ]]>
            </query>
        </rules>
    </processor>

    <ha:ha-buffering-adapter >
        <name>myHaSlidingWindowAdapter</name>
        <window-length>0</window-length>
    </ha:ha-buffering-adapter >

</wlevs:config>

    For more information, see:

  8. Deploy your application to the deployment group you created in step 1.

    For more information, see Section 23.5, "Deploying Oracle Event Processing Applications".

    Oracle Event Processing automatically selects one of the Oracle Event Processing servers as the primary.

24.2.1.2 How to Configure Simple Failover With Buffering

You configure simple failover using the Oracle Event Processing buffering output adapter with a sliding window size greater than zero (0).

This procedure starts with the example EPN that Figure 24-10 shows and adds the required components to configure it for simple failover with buffering. Example 24-7 shows the corresponding EPN assembly file and Example 24-8 shows the corresponding component configuration file.

For more information about this Oracle Event Processing high availability quality of service, see Section 24.1.2.2, "Simple Failover with Buffering".

Figure 24-10 Simple Failover With Buffering EPN

Description of Figure 24-10 follows
Description of "Figure 24-10 Simple Failover With Buffering EPN"

Example 24-7 Simple Failover With Buffering EPN Assembly File

<?xml version="1.0" encoding="UTF-8"?>
<beans ...>

    <wlevs:event-type-repository>
        <wlevs:event-type type-name="HelloWorldEvent">
            <wlevs:class>com.bea.wlevs.event.example.helloworld.HelloWorldEvent</wlevs:class>
        </wlevs:event-type>
    </wlevs:event-type-repository>

    <wlevs:adapter id="helloworldAdapter" 
        class="com.bea.wlevs.adapter.example.helloworld.HelloWorldAdapter" >
        <wlevs:instance-property name="message" value="HelloWorld - the current time is:"/>
    </wlevs:adapter>

    <wlevs:channel id="helloworldInputChannel" event-type="HelloWorldEvent" >
        <wlevs:listener ref="helloworldProcessor"/>
        <wlevs:source ref="helloworldAdapter"/>
    </wlevs:channel>

    <wlevs:processor id="helloworldProcessor" />
    
    <wlevs:channel id="helloworldOutputChannel" 
        event-type="HelloWorldEvent" advertise="true">
        <wlevs:listener>
            <bean class="com.bea.wlevs.example.helloworld.HelloWorldBean"/>
        </wlevs:listener>
        <wlevs:source ref="helloworldProcessor"/>
    </wlevs:channel>

</beans>

Example 24-8 Simple Failover With Buffering Component Configuration Assembly File

<?xml version="1.0" encoding="UTF-8"?>
<wlevs:config 
        xmlns:wlevs="http://www.bea.com/ns/wlevs/config/application"
        xmlns:ha="http://www.oracle.com/ns/cep/config/cluster/">
    <processor>
        <name>helloworldProcessor</name>
        <rules>
            <query id="helloworldRule">
                <![CDATA[ select * from helloworldInputChannel [Now] ]]>
            </query>
        </rules>
    </processor>
</wlevs:config>

To configure simple failover with buffering:

  1. Create a multi-server domain using Oracle Coherence.

    For more information, see:

  2. Create an Oracle Event Processing application.

    For more information, see Section 5.2, "Creating Oracle Event Processing Projects".

  3. Edit the MANIFEST.MF file to add the following Import-Package entries:

    • com.bea.wlevs.ede.api.cluster

    • com.oracle.cep.cluster.hagroups

    • com.oracle.cep.cluster.ha.adapter

    • com.oracle.cep.cluster.ha.api

    For more information, see Section 5.7.2, "How to Add an OSGi Bundle to an Oracle Event Processing Project".

  4. Configure your Oracle Event Processing application EPN assembly file to add an Oracle Event Processing high availability buffering output adapter as Example 24-3 shows.

    • Add a wlevs:adapter element with provider set to ha-buffering after channel helloworldOutputChannel.

    • Update the wlevs:listener element in channel helloworldOutputChannel to reference the ha-buffering adapter by its id.

    • Add a wlevs:listener element to the ha-buffering adapter that references the HelloWorldBean class.

    Example 24-9 Simple Failover EPN Assembly File: Buffering Output Adapter

    <?xml version="1.0" encoding="UTF-8"?>
<beans ...>

    <wlevs:event-type-repository>
        <wlevs:event-type type-name="HelloWorldEvent">
            <wlevs:class>com.bea.wlevs.event.example.helloworld.HelloWorldEvent</wlevs:class>
        </wlevs:event-type>
    </wlevs:event-type-repository>

    <wlevs:adapter id="helloworldAdapter" 
        class="com.bea.wlevs.adapter.example.helloworld.HelloWorldAdapter" >
        <wlevs:instance-property name="message" value="HelloWorld - the current time is:"/>
    </wlevs:adapter>

    <wlevs:channel id="helloworldInputChannel" event-type="HelloWorldEvent" >
        <wlevs:listener ref="helloworldProcessor"/>
    </wlevs:channel>

    <wlevs:processor id="helloworldProcessor" />

    <wlevs:channel id="helloworldOutputChannel" event-type="HelloWorldEvent" 
        advertise="true">
        <wlevs:listener ref="myHaSlidingWindowAdapter"/>
        <wlevs:source ref="helloworldProcessor"/>
    </wlevs:channel>

    <wlevs:adapter id="myHaSlidingWindowAdapter" provider="ha-buffering" >
        <wlevs:listener>
            <bean class="com.bea.wlevs.example.helloworld.HelloWorldBean"/>
        </wlevs:listener>
    </wlevs:adapter>

</beans>

  5. Optionally, configure the channel downstream from the input adapter (helloworldInputChannel) to configure an application timestamp based on an appropriate event property as Example 24-10 shows.

    For simple failover with buffering, you can use system timestamps because events are not correlated between servers. However, it is possible that slightly different results might be output from the buffer if application timestamps are not used.

    In this example, event property arrivalTime is used.

    The wlevs:expression should be set to this event property.

    Example 24-10 Application Timestamp Configuration

    ...
    <wlevs:channel id="helloworldInputChannel" event-type="HelloWorldEvent" >
        <wlevs:listener ref="helloworldProcessor"/>
        <wlevs:source ref="myHaInputAdapter"/>
        <wlevs:application-timestamped>
            <wlevs:expression>arrivalTime</wlevs:expression>
        </wlevs:application-timestamped>
    </wlevs:channel>
...

  6. Configure the Oracle Event Processing high availability buffering output adapter.

    Set the instance property windowLength to a value greater than zero (0) as Example 24-11 shows.

    Example 24-11 Configuring windowLength in the Buffering Output Adapter

    ...
    <wlevs:adapter id="myHaSlidingWindowAdapter" provider="ha-buffering" >
        <wlevs:listener>
            <bean class="com.bea.wlevs.example.helloworld.HelloWorldBean"/>
        </wlevs:listener>
        <wlevs:instance-property name="windowLength" value="15000"/>
    </wlevs:adapter>
...

    For more information, see Section 24.2.2.2.1, "Buffering Output Adapter EPN Assembly File Configuration".

  7. Optionally, configure the component configuration file to include the Oracle Event Processing high availability buffering output adapter as Example 24-12 shows.

    Example 24-12 Simple Failover With Buffering Component Configuration File

    <?xml version="1.0" encoding="UTF-8"?>
<wlevs:config 
        xmlns:wlevs="http://www.bea.com/ns/wlevs/config/application"
        xmlns:ha="http://www.oracle.com/ns/cep/config/cluster/">
    <processor>
        <name>helloworldProcessor</name>
        <rules>
            <query id="helloworldRule">
                <![CDATA[ select * from helloworldInputChannel [Now] ]]>
            </query>
        </rules>
    </processor>

    <ha:ha-buffering-adapter >
        <name>myHaSlidingWindowAdapter</name>
        <window-length>15000</window-length>
    </ha:ha-buffering-adapter >

</wlevs:config>

    For more information, see:

  8. If your application is an Oracle Event Processing high availability Type 1 application (the application must generate exactly the same sequence of output events as existing secondaries), configure the warm-up-window-length for the buffering output adapter.

    For more information, see:

  9. Deploy your application to the deployment group you created in step 1.

    For more information, see Section 23.5, "Deploying Oracle Event Processing Applications".

    Oracle Event Processing automatically selects one of the Oracle Event Processing servers as the primary.

24.2.1.3 How to Configure Light-Weight Queue Trimming

You configure light-weight queue trimming using the Oracle Event Processing high availability input adapter and the broadcast output adapter.

This procedure starts with the example EPN that Figure 24-11 shows and adds the required components to configure it for light-weight queue trimming. Example 24-13 shows the corresponding EPN assembly file and Example 24-14 shows the corresponding component configuration file.

For more information about this Oracle Event Processing high availability quality of service, see Section 24.1.2.3, "Light-Weight Queue Trimming".

Figure 24-11 Light-Weight Queue Trimming EPN

Description of Figure 24-11 follows
Description of "Figure 24-11 Light-Weight Queue Trimming EPN"

Example 24-13 Light-Weight Queue Trimming EPN Assembly File

<?xml version="1.0" encoding="UTF-8"?>
<beans ...>

    <wlevs:event-type-repository>
        <wlevs:event-type type-name="HelloWorldEvent">
            <wlevs:class>com.bea.wlevs.event.example.helloworld.HelloWorldEvent</wlevs:class>
        </wlevs:event-type>
    </wlevs:event-type-repository>

    <wlevs:adapter id="helloworldAdapter" 
        class="com.bea.wlevs.adapter.example.helloworld.HelloWorldAdapter" >
        <wlevs:instance-property name="message" value="HelloWorld - the current time is:"/>
    </wlevs:adapter>

    <wlevs:channel id="helloworldInputChannel" event-type="HelloWorldEvent" >
        <wlevs:listener ref="helloworldProcessor"/>
        <wlevs:source ref="helloworldAdapter"/>
    </wlevs:channel>

    <wlevs:processor id="helloworldProcessor" />
    
    <wlevs:channel id="helloworldOutputChannel" event-type="HelloWorldEvent" 
        advertise="true">
        <wlevs:listener>
            <bean class="com.bea.wlevs.example.helloworld.HelloWorldBean"/>
        </wlevs:listener>
        <wlevs:source ref="helloworldProcessor"/>
    </wlevs:channel>

</beans>

Example 24-14 Light-Weight Queue Trimming Component Configuration Assembly File

<?xml version="1.0" encoding="UTF-8"?>
<wlevs:config 
        xmlns:wlevs="http://www.bea.com/ns/wlevs/config/application"
        xmlns:ha="http://www.oracle.com/ns/cep/config/cluster/">
    <processor>
        <name>helloworldProcessor</name>
        <rules>
            <query id="helloworldRule">
                <![CDATA[ select * from helloworldInputChannel [Now] ]]>
            </query>
        </rules>
    </processor>
</wlevs:config>

To configure light-weight queue trimming:

  1. Create a multi-server domain using Oracle Coherence.

    For more information, see:

  2. Create an Oracle Event Processing application.

    For more information, see Section 5.2, "Creating Oracle Event Processing Projects".

  3. Edit the MANIFEST.MF file to add the following Import-Package entries:

    • com.bea.wlevs.ede.api.cluster

    • com.oracle.cep.cluster.hagroups

    • com.oracle.cep.cluster.ha.adapter

    • com.oracle.cep.cluster.ha.api

    For more information, see Section 5.7.2, "How to Add an OSGi Bundle to an Oracle Event Processing Project".

  4. Configure your Oracle Event Processing application EPN assembly file to add an Oracle Event Processing high availability input adapter as Example 24-15 shows:

    • Add a wlevs:adapter element with provider set to ha-inbound after the regular input adapter helloworldAdapter.

    • Add a wlevs:listener element to the regular input adapter helloworldAdapter that references the ha-inbound adapter by its id.

    • Add a wlevs:source element to the helloworldInputChannel that references the ha-inbound adapter by its id.

    Example 24-15 Light-Weight Queue Trimming EPN Assembly File: High Availability Input Adapter

    <?xml version="1.0" encoding="UTF-8"?>
<beans ...>

    <wlevs:event-type-repository>
        <wlevs:event-type type-name="HelloWorldEvent">
            <wlevs:class>com.bea.wlevs.event.example.helloworld.HelloWorldEvent</wlevs:class>
        </wlevs:event-type>
    </wlevs:event-type-repository>

    <wlevs:adapter id="helloworldAdapter" 
        class="com.bea.wlevs.adapter.example.helloworld.HelloWorldAdapter" >
        <wlevs:instance-property name="message" value="HelloWorld - the current time is:"/>
        <wlevs:listener ref="myHaInputAdapter"/>
    </wlevs:adapter>

    <wlevs:adapter id="myHaInputAdapter" provider="ha-inbound" >
    </wlevs:adapter>

    <wlevs:channel id="helloworldInputChannel" event-type="HelloWorldEvent" >
        <wlevs:listener ref="helloworldProcessor"/>
        <wlevs:source ref="myHaInputAdapter"/>
    </wlevs:channel>

    <wlevs:processor id="helloworldProcessor" />

    <wlevs:channel id="helloworldOutputChannel" event-type="HelloWorldEvent" 
        advertise="true">
        <wlevs:listener>
            <bean class="com.bea.wlevs.example.helloworld.HelloWorldBean"/>
        </wlevs:listener>
        <wlevs:source ref="helloworldProcessor"/>
    </wlevs:channel>

</beans>

  5. Configure your Oracle Event Processing application EPN assembly file to add an Oracle Event Processing high availability broadcast output adapter as Example 24-16 shows.

    • Add a wlevs:adapter element with provider set to ha-broadcast after channel helloworldOutputChannel.

    • Update the wlevs:listener element in channel helloworldOutputChannel to reference the ha-broadcast adapter by its id.

    • Add a wlevs:listener element to the ha-broadcast adapter that references the HelloWorldBean class.

    Example 24-16 Light-Weight Queue Trimming EPN Assembly File: Broadcast Output Adapter

    <?xml version="1.0" encoding="UTF-8"?>
<beans ...>

    <wlevs:event-type-repository>
        <wlevs:event-type type-name="HelloWorldEvent">
            <wlevs:class>com.bea.wlevs.event.example.helloworld.HelloWorldEvent</wlevs:class>
        </wlevs:event-type>
    </wlevs:event-type-repository>

    <wlevs:adapter id="helloworldAdapter" 
        class="com.bea.wlevs.adapter.example.helloworld.HelloWorldAdapter" >
        <wlevs:instance-property name="message" value="HelloWorld - the current time is:"/>
        <wlevs:listener ref="myHaInputAdapter"/>
    </wlevs:adapter>

    <wlevs:adapter id="myHaInputAdapter" provider="ha-inbound" >
    </wlevs:adapter>

    <wlevs:channel id="helloworldInputChannel" event-type="HelloWorldEvent" >
        <wlevs:listener ref="helloworldProcessor"/>
        <wlevs:source ref="myHaInputAdapter"/>
    </wlevs:channel>

    <wlevs:processor id="helloworldProcessor" />

    <wlevs:channel id="helloworldOutputChannel" event-type="HelloWorldEvent" 
        advertise="true">
        <wlevs:listener ref="myHaBroadcastAdapter"/>
        <wlevs:source ref="helloworldProcessor"/>
    </wlevs:channel>

    <wlevs:adapter id="myHaBroadcastAdapter" provider="ha-broadcast" >
        <wlevs:listener>
            <bean class="com.bea.wlevs.example.helloworld.HelloWorldBean"/>
        </wlevs:listener>
    </wlevs:adapter>

</beans>

  6. Configure the Oracle Event Processing high availability input adapter.

    Consider the following example configurations:

    For more information, see Section 24.2.2.1.1, "High Availability Input Adapter EPN Assembly File Configuration".

    Example 24-17 High Availability Input Adapter: Default Configuration

    This example shows a high availability input adapter configuration using all defaults. The mandatory key is based on all event properties and the event property that the high availability input adapter assigns a time value to is an event property named arrivalTime.

    ...
    <wlevs:adapter id="myHaInputAdapter" provider="ha-inbound" >
        <wlevs:instance-property name="timeProperty" value="arrivalTime"/>
    </wlevs:adapter>
...

    Example 24-18 High Availability Input Adapter: Tuple Events

    This example shows a high availability input adapter configuration using all defaults. The mandatory key is based on all event properties and the event property that the high availability input adapter assigns a time value to is an event property named arrivalTime. Because the events are tuple-based events, you must specify the event type (MyEventType) using the eventType property.

    ...
    <wlevs:adapter id="myHaInputAdapter" provider="ha-inbound" >
        <wlevs:instance-property name="timeProperty" value="arrivalTime"/>
        <wlevs:instance-property name="eventType" value="MyEventType"/>
    </wlevs:adapter>
...

    Example 24-19 High Availability Input Adapter: Key of One Event Property

    This example shows a high availability input adapter configuration where the mandatory key is based on one event property (named id) and the event property that the high availability input adapter assigns a time value to is an event property named arrivalTime.

    ...
    <wlevs:adapter id="myHaInputAdapter" provider="ha-inbound" >
        <wlevs:instance-property name="keyProperties" value="id"/>
        <wlevs:instance-property name="timeProperty" value="arrivalTime"/>
    </wlevs:adapter>
...

    Example 24-20 High Availability Input Adapter: Key of Multiple Event Properties

    This example shows a high availability input adapter configuration where the mandatory key is based on more than one event property (properties orderID and accountID) and the event property that the high availability input adapter assigns a time value to is an event property named arrivalTime. A compound key Java class (com.acme.MyCompoundKeyClass) is mandatory and its implementation is shown in Example 24-21. The hashCode and equals methods are required. When you specify a keyClass, the keyProperties instance property is ignored: Oracle Event Processing assumes that the compound key is based on all the getter methods in the keyClass.

    ...
    <wlevs:adapter id="myHaInputAdapter" provider="ha-inbound" >
        <wlevs:instance-property name="timeProperty" value="arrivalTime"/>
        <wlevs:instance-property name="keyClass" value="com.acme.MyCompoundKeyClass"/>
    </wlevs:adapter>
...

    Example 24-21 MyCompoundKeyClass Implementation

    package com.acme;

public class MyCompoundKeyClass {
    private int orderID;
    private int accountID;

    public MyCompoundKeyClass() {}

    public int getOrderID() {
        return orderID;
    }
    public setOrderID(int orderID) {
        this.orderID = orderID;
    }
    public int getAccountID() {
        return accountID;
    }
    public setOrderID(int accountID) {
        this.accountID = accountID;
    }

    public int hashCode() {
    int hash = 1;
    hash = hash * 31 + orderID.hashCode();
    hash = hash * 31 + (accountID == null ? 0 : accountID.hashCode());
    return hash;
    }

    public boolean equals(Object obj) {
        if (obj == this) return true;
        if (obj == null) return false;
        if (!(obj instanceof MyCompoundKeyClass)) return false;
        MyCompoundKeyClass k = (MyCompoundKeyClass) obj;
        return k.accountID == accountID && k.orderID == orderID;
    }
}

  7. Configure the channel downstream from the high availability input adapter (helloworldInputChannel) to configure an application timestamp based on the high availability input adapter timeProperty setting as Example 24-22 shows.

    The wlevs:expression should be set to the timeProperty value.

    Example 24-22 Application Timestamp Configuration

    ...
    <wlevs:adapter id="myHaInputAdapter" provider="ha-inbound" >
        <wlevs:instance-property name="keyProperties" value="id"/>
        <wlevs:instance-property name="eventType" value="HelloWorldEvent"/>
        <wlevs:instance-property name="timeProperty" value="arrivalTime"/>
    </wlevs:adapter>

    <wlevs:channel id="helloworldInputChannel" event-type="HelloWorldEvent" >
        <wlevs:listener ref="helloworldProcessor"/>
        <wlevs:source ref="myHaInputAdapter"/>
        <wlevs:application-timestamped>
            <wlevs:expression>arrivalTime</wlevs:expression>
        </wlevs:application-timestamped>
    </wlevs:channel>
...

  8. Configure the Oracle Event Processing high availability broadcast output adapter.

    Consider the following example configurations:

    For more information, see Section 24.2.2.3.1, "Broadcast Output Adapter EPN Assembly File Configuration".

    Example 24-23 Broadcast Output Adapter: Default Configuration

    This example shows a broadcast output adapter configuration using all defaults. The mandatory key is based on all event properties, key values are nonmonotonic (do not increase continually) and total order (unique).

    ...
    <wlevs:adapter id="myHaSlidingWindowAdapter" provider="ha-broadcast" >
        <wlevs:listener>
            <bean class="com.bea.wlevs.example.helloworld.HelloWorldBean"/>
        </wlevs:listener>
    </wlevs:adapter>
...

    Example 24-24 Broadcast Output Adapter: Key of One Event Property

    This example shows a broadcast output adapter configuration where the mandatory key is based on one event property (named timeProperty), key values are monotonic (they do increase continually) and not total order (not unique).

    ...
    <wlevs:adapter id="myHaSlidingWindowAdapter" provider="ha-broadcast" >
        <wlevs:listener>
            <bean class="com.bea.wlevs.example.helloworld.HelloWorldBean"/>
        </wlevs:listener>
        <wlevs:instance-property name="keyProperties" value="timeProperty"/>
        <wlevs:instance-property name="monotonic" value="true"/>
        <wlevs:instance-property name="totalOrder" value="false"/>
    </wlevs:adapter>
...

    Example 24-25 Broadcast Output Adapter: Key of Multiple Event Properties

    This example shows a broadcast output adapter configuration where the mandatory key is based on more than one event property (properties timeProperty and accountID), key values are monotonic (they do increase continually) and total order (unique). A compound key Java class (com.acme.MyCompoundKeyClass) is mandatory and its implementation is shown in Example 24-26. The hashCode and equals methods are required. When you specify a keyClass, the keyProperties instance property is ignored: Oracle Event Processing assumes that the compound key is based on all the getter methods in the keyClass.

    ...
    <wlevs:adapter id="myHaSlidingWindowAdapter" provider="ha-broadcast" >
        <wlevs:listener>
            <bean class="com.bea.wlevs.example.helloworld.HelloWorldBean"/>
        </wlevs:listener>
        <wlevs:instance-property name="keyClass" value="com.acme.MyCompoundKeyClass"/>
        <wlevs:instance-property name="monotonic" value="true"/>
        <wlevs:instance-property name="totalOrder" value="true"/>
    </wlevs:adapter>
...

    Example 24-26 MyCompoundKeyClass Implementation

    package com.acme;

public class MyCompoundKeyClass {
    private int timeProperty;
    private int accountID;

    public MyCompoundKeyClass() {}

    public int getTimeProperty() {
        return orderID;
    }
    public setTimeProperty(int timeProperty) {
        this.timeProperty = timeProperty;
    }
    public int getAccountID() {
        return accountID;
    }
    public setOrderID(int accountID) {
        this.accountID = accountID;
    }

    public int hashCode() {
    int hash = 1;
    hash = hash * 31 + timeProperty.hashCode();
    hash = hash * 31 + (accountID == null ? 0 : accountID.hashCode());
    return hash;
    }

    public boolean equals(Object obj) {
        if (obj == this) return true;
        if (obj == null) return false;
        if (!(obj instanceof MyCompoundKeyClass)) return false;
        MyCompoundKeyClass k = (MyCompoundKeyClass) obj;
        return k.accountID == accountID && k.orderID == orderID;
    }
}

  9. Optionally, configure the component configuration file to include the Oracle Event Processing high availability input adapter and buffering output adapter as Example 24-27 shows.

    Example 24-27 Light-Weight Queue Trimming Component Configuration File

    <?xml version="1.0" encoding="UTF-8"?>
<wlevs:config 
        xmlns:wlevs="http://www.bea.com/ns/wlevs/config/application"
        xmlns:ha="http://www.oracle.com/ns/cep/config/cluster/">
    <processor>
        <name>helloworldProcessor</name>
        <rules>
            <query id="helloworldRule">
                <![CDATA[ select * from helloworldInputChannel [Now] ]]>
            </query>
        </rules>
    </processor>

    <ha:ha-inbound-adapter>
        <name>myHaInputAdapter</name>
    </ha:ha-inbound-adapter>
 
    <ha:ha-broadcast-adapter>
        <name>myHaBroadcastAdapter</name>
        <trimming-interval units="events">10</trimming-interval>
    </ha:ha-broadcast-adapter>

</wlevs:config>

    For more information, see:

  10. If your application is an Oracle Event Processing high availability Type 1 application (the application must generate exactly the same sequence of output events as existing secondaries), configure the warm-up-window-length for the broadcast output adapter.

    For more information, see:

  11. Deploy your application to the deployment group you created in step 1.

    For more information, see Section 23.5, "Deploying Oracle Event Processing Applications".

    Oracle Event Processing automatically selects one of the Oracle Event Processing servers as the primary.

24.2.1.4 How to Configure Precise Recovery With JMS

You configure precise recovery with JMS using the Oracle Event Processing high availability input adapter and correlating output adapter.

This procedure describes how to create the example EPN that Figure 24-12 shows. Example 24-28 shows the corresponding EPN assembly file and Example 24-29 shows the corresponding component configuration file.

For more information about this Oracle Event Processing high availability quality of service, see Section 24.1.2.4, "Precise Recovery with JMS".

Note:

The JMS destination used by JMS adapters for precise recovery must be topics, rather than queues.

Figure 24-12 Precise Recovery With JMS EPN

Description of Figure 24-12 follows
Description of "Figure 24-12 Precise Recovery With JMS EPN"

Example 24-28 Precise Recovery With JMS EPN Assembly File

<?xml version="1.0" encoding="UTF-8"?>
<beans ... >

    <wlevs:event-type-repository>
        <wlevs:event-type type-name="StockTick">
            <wlevs:properties>
                <wlevs:property name="lastPrice" type="double" />
                <wlevs:property name="symbol" type="char" />
            </wlevs:properties>
        </wlevs:event-type>
    </wlevs:event-type-repository>

    <wlevs:adapter id="JMSInboundAdapter" provider="jms-inbound">
        <wlevs:listener ref="myHaInputAdapter"/>
    </wlevs:adapter>

    <wlevs:adapter id="myHaInputAdapter" provider="ha-inbound" >
        <wlevs:instance-property name="keyProperties" value="sequenceNo"/>
        <wlevs:instance-property name="timeProperty" value="inboundTime"/>
    </wlevs:adapter>

    <wlevs:channel id="channel1" event-type="StockTick">
        <wlevs:listener ref="processor1" />
        <wlevs:source ref="myHaInputAdapter"/>
        <wlevs:application-timestamped>
            <wlevs:expression>inboundTime</wlevs:expression>
        </wlevs:application-timestamped>
    </wlevs:channel>

    <wlevs:processor id="processor1">
        <wlevs:listener ref="channel2" />
    </wlevs:processor>

    <wlevs:adapter id="myHaCorrelatingAdapter" provider="ha-correlating" >
        <wlevs:instance-property name="correlatedSource" ref="clusterCorrelatingOutstream"/> 
        <wlevs:instance-property name="failOverDelay" value="2000"/> 
        <wlevs:listener ref="JMSOutboundAdapter"/>
    </wlevs:adapter>

    <wlevs:channel id="channel2" event-type="StockTick">
        <wlevs:listener ref="myHaCorrelatingAdapter" />
    </wlevs:channel>

    <wlevs:adapter id="JMSOutboundAdapter" provider="jms-outbound">
    </wlevs:adapter>

    <wlevs:adapter id="JMSInboundAdapter2" provider="jms-inbound">
    </wlevs:adapter>

    <wlevs:channel id="clusterCorrelatingOutstream" event-type="StockTick" advertise="true">
        <wlevs:source ref="JMSInboundAdapter2"/>
    </wlevs:channel> 
</beans>

Example 24-29 Precise Recovery With JMS Component Configuration Assembly File

<?xml version="1.0" encoding="UTF-8"?>
<wlevs:config 
        xmlns:wlevs="http://www.bea.com/ns/wlevs/config/application"
        xmlns:ha="http://www.oracle.com/ns/cep/config/cluster/">
    <processor>
        <name>processor1</name>
        <rules>
            <query id="helloworldRule">
                <![CDATA[ select * from channel1 [Now] ]]>
            </query>
        </rules>
    </processor>
</wlevs:config>

To configure precise recovery with JMS:

  1. Create a multi-server domain using Oracle Coherence.

    For more information, see:

  2. Create an Oracle Event Processing application.

    For more information, see Section 5.2, "Creating Oracle Event Processing Projects".

  3. Edit the MANIFEST.MF file to add the following Import-Package entries:

    • com.bea.wlevs.ede.api.cluster

    • com.oracle.cep.cluster.hagroups

    • com.oracle.cep.cluster.ha.adapter

    • com.oracle.cep.cluster.ha.api

    For more information, see Section 5.7.2, "How to Add an OSGi Bundle to an Oracle Event Processing Project".

  4. Configure your Oracle Event Processing application EPN assembly file to add an Oracle Event Processing high availability input adapter as Example 24-30 shows:

    • Add a wlevs:adapter element with provider set to ha-inbound after the regular input adapter JMSInboundAdapter.

    • Add a wlevs:listener element to the regular input adapter JMSInboundAdapter that references the ha-inbound adapter by its id.

    • Add a wlevs:source element to the channel channel1 that references the ha-inbound adapter by its id.

    Example 24-30 Precise Recovery With JMS EPN Assembly File: High Availability Input Adapter

    <?xml version="1.0" encoding="UTF-8"?>
<beans ...>

    <wlevs:event-type-repository>
        <wlevs:event-type type-name="StockTick">
            <wlevs:properties>
                <wlevs:property name="lastPrice" type="double" />
                <wlevs:property name="symbol" type="char" />
            </wlevs:properties>
        </wlevs:event-type>
    </wlevs:event-type-repository>

    <wlevs:adapter id="JMSInboundAdapter" provider="jms-inbound">
        <wlevs:listener ref="myHaInputAdapter"/>
    </wlevs:adapter>

    <wlevs:adapter id="myHaInputAdapter" provider="ha-inbound" >
    </wlevs:adapter>

    <wlevs:channel id="channel1" event-type="StockTick">
        <wlevs:listener ref="processor1" />
        <wlevs:source ref="myHaInputAdapter"/>
    </wlevs:channel>

...

</beans>

  5. Configure your Oracle Event Processing application EPN assembly file to add an Oracle Event Processing high availability correlating output adapter as Example 24-31 shows.

    • Add a wlevs:adapter element with provider set to ha-correlating after channel channel2.

    • Update the wlevs:listener element in channel channel2 to reference the ha-correlating adapter by its id.

    • Add a wlevs:listener element to the ha-correlating adapter that references the regular output adapter JMSOutboundAdapter.

    Example 24-31 Precise Recovery With JMS EPN Assembly File: Correlating Output Adapter

    <?xml version="1.0" encoding="UTF-8"?>
<beans ...>

    <wlevs:event-type-repository>
        <wlevs:event-type type-name="StockTick">
            <wlevs:properties>
                <wlevs:property name="lastPrice" type="double" />
                <wlevs:property name="symbol" type="char" />
            </wlevs:properties>
        </wlevs:event-type>
    </wlevs:event-type-repository>

    <wlevs:adapter id="JMSInboundAdapter" provider="jms-inbound">
        <wlevs:listener ref="myHaInputAdapter"/>
    </wlevs:adapter>

    <wlevs:adapter id="myHaInputAdapter" provider="ha-inbound" >
    </wlevs:adapter>

    <wlevs:channel id="channel1" event-type="StockTick">
        <wlevs:listener ref="processor1" />
        <wlevs:source ref="myHaInputAdapter"/>
    </wlevs:channel>

    <wlevs:processor id="processor1">
        <wlevs:listener ref="channel2" />
    </wlevs:processor>

    <wlevs:channel id="channel2" event-type="StockTick">
        <wlevs:listener ref="myHaCorrelatingAdapter" />
    </wlevs:channel>

    <wlevs:adapter id="myHaCorrelatingAdapter" provider="ha-correlating" >
        <wlevs:listener ref="JMSOutboundAdapter"/>
    </wlevs:adapter>

    <wlevs:adapter id="JMSOutboundAdapter" provider="jms-outbound">
    </wlevs:adapter>

...

</beans>

  6. Configure the Oracle Event Processing high availability input adapter.

    Consider the following example configurations:

    For more information, see Section 24.2.2.1.1, "High Availability Input Adapter EPN Assembly File Configuration".

    Example 24-32 High Availability Input Adapter: Default Configuration

    This example shows a high availability input adapter configuration using all defaults. The mandatory key is based on all event properties and the event property that the high availability input adapter assigns a time value to is an event property named arrivalTime.

    ...
    <wlevs:adapter id="myHaInputAdapter" provider="ha-inbound" >
        <wlevs:instance-property name="timeProperty" value="arrivalTime"/>
    </wlevs:adapter>
...

    Example 24-33 High Availability Input Adapter: Tuple Events

    This example shows a high availability input adapter configuration using all defaults. The mandatory key is based on all event properties and the event property that the high availability input adapter assigns a time value to is an event property named arrivalTime. Because the events are tuple-based events, you must specify the event type (MyEventType) using the eventType property.

    ...
    <wlevs:adapter id="myHaInputAdapter" provider="ha-inbound" >
        <wlevs:instance-property name="timeProperty" value="arrivalTime"/>
        <wlevs:instance-property name="eventType" value="MyEventType"/>
    </wlevs:adapter>
...

    Example 24-34 High Availability Input Adapter: Key of One Event Property

    This example shows a high availability input adapter configuration where the mandatory key is based on one event property (named sequenceNo) and the event property that the high availability input adapter assigns a time value to is an event property named inboundTime.

    ...
    <wlevs:adapter id="myHaInputAdapter" provider="ha-inbound" >
        <wlevs:instance-property name="keyProperties" value="sequenceNo"/>
        <wlevs:instance-property name="timeProperty" value="inboundTime"/>
    </wlevs:adapter>
...

    Example 24-35 High Availability Input Adapter: Key of Multiple Event Properties

    This example shows a high availability input adapter configuration where the mandatory key is based on more than one event property (properties orderID and accountID) and the event property that the high availability input adapter assigns a time value to is an event property named arrivalTime. A compound key Java class (com.acme.MyCompoundKeyClass) is mandatory and its implementation is shown in Example 24-36. The hashCode and equals methods are required. When you specify a keyClass, the keyProperties instance property is ignored: Oracle Event Processing assumes that the compound key is based on all the getter methods in the keyClass.

    ...
    <wlevs:adapter id="myHaInputAdapter" provider="ha-inbound" >
        <wlevs:instance-property name="timeProperty" value="arrivalTime"/>
        <wlevs:instance-property name="keyClass" value="com.acme.MyCompoundKeyClass"/>
    </wlevs:adapter>
...

    Example 24-36 MyCompoundKeyClass Implementation

    package com.acme;

public class MyCompoundKeyClass {
    private int orderID;
    private int accountID;

    public MyCompoundKeyClass() {}

    public int getOrderID() {
        return orderID;
    }
    public setOrderID(int orderID) {
        this.orderID = orderID;
    }
    public int getAccountID() {
        return accountID;
    }
    public setOrderID(int accountID) {
        this.accountID = accountID;
    }

    public int hashCode() {
    int hash = 1;
    hash = hash * 31 + orderID.hashCode();
    hash = hash * 31 + (accountID == null ? 0 : accountID.hashCode());
    return hash;
    }

    public boolean equals(Object obj) {
        if (obj == this) return true;
        if (obj == null) return false;
        if (!(obj instanceof MyCompoundKeyClass)) return false;
        MyCompoundKeyClass k = (MyCompoundKeyClass) obj;
        return k.accountID == accountID && k.orderID == orderID;
    }
}

  7. Configure the channel downstream from the high availability input adapter (channel1) to configure an application timestamp based on the high availability input adapter timeProperty setting as Example 24-37 shows.

    The wlevs:expression should be set to the timeProperty value.

    Example 24-37 Application Timestamp Configuration

    ...
    <wlevs:adapter id="myHaInputAdapter" provider="ha-inbound" >
        <wlevs:instance-property name="eventType" value="HelloWorldEvent"/>
        <wlevs:instance-property name="keyProperties" value="sequenceNo"/>
        <wlevs:instance-property name="timeProperty" value="inboundTime"/>
    </wlevs:adapter>

    <wlevs:channel id="channel1" event-type="StockTick">
        <wlevs:listener ref="processor1" />
        <wlevs:source ref="myHaInputAdapter"/>
        <wlevs:application-timestamped>
            <wlevs:expression>inboundTime</wlevs:expression>
        </wlevs:application-timestamped>
    </wlevs:channel>
...

  8. Configure the Oracle Event Processing high availability correlating output adapter failOverDelay.

    Example 24-38 shows a correlating output adapter configuration where the failOverDelay is 2000 milliseconds.

    Example 24-38 Correlating Output Adapter Configuration: failOverDelay

    ...
    <wlevs:adapter id="myHaCorrelatingAdapter" provider="ha-correlating" >
        <wlevs:listener ref="JMSOutboundAdapter"/>
        <wlevs:instance-property name="failOverDelay" value="2000"/>
    </wlevs:adapter>
...

    For more information, see Section 24.2.2.4.1, "Correlating Output Adapter EPN Assembly File Configuration".

  9. Create a second regular JMS input adapter.

    Example 24-39 shows a JMS adapter named JMSInboundAdapter2.

    Example 24-39 Inbound JMS Adapter Assembly File

    ...
    <wlevs:adapter id="JMSInboundAdapter2" provider="jms-inbound">
    </wlevs:adapter>
...

    This JMS input adapter must be configured identically to the first JMS input adapter (in this example, JMSInboundAdapter). Example 24-40 shows the component configuration file for both the JMS input adapters. Note that both have exactly the same configuration, including the same provider.

    Example 24-40 Inbound JMS Adapter Component Configuration File

    <?xml version="1.0" encoding="UTF-8"?>
<wlevs:config 
        xmlns:wlevs="http://www.bea.com/ns/wlevs/config/application"
        xmlns:ha="http://www.oracle.com/ns/cep/config/cluster/">
    ...
    <jms-adapter>
        <name>JMSInboundAdapter</name>
        <jndi-provider-url>t3://localhost:7001</jndi-provider-url>
        <destination-jndi-name>./Topic1</destination-jndi-name>
        <user>weblogic</user>
        <password>weblogic</password>
        <work-manager>JettyWorkManager</work-manager>
        <concurrent-consumers>1</concurrent-consumers>
    </jms-adapter>

    <jms-adapter>
        <name>JMSInboundAdapter2</name>
        <jndi-provider-url>t3://localhost:7001</jndi-provider-url>
        <destination-jndi-name>./Topic1</destination-jndi-name>
        <user>weblogic</user>
        <password>weblogic</password>
        <work-manager>JettyWorkManager</work-manager>
        <concurrent-consumers>1</concurrent-consumers>
    </jms-adapter>
    ...
</wlevs:config>

  10. Create a channel to function as the correlated source.

    You must configure this channel with the second regular JMS input adapter as its source.

    Example 24-41 shows a correlated source named clusterCorrelatingOutstream whose source is JMSInboundAdapter2.

    Example 24-41 Creating the Correlated Source

    ...
    <wlevs:adapter id="JMSInboundAdapter2" provider="jms-inbound">
    </wlevs:adapter>

    <wlevs:channel id="clusterCorrelatingOutstream" event-type="StockTick" advertise="true">
        <wlevs:source ref="JMSInboundAdapter2"/>
    </wlevs:channel>

  11. Configure the Oracle Event Processing high availability correlating output adapter with the correlatedSource.

    Example 24-38 shows a correlating output adapter configuration where the correlatedSource is clusterCorrelatingOutstream.

    Example 24-42 Correlating Output Adapter: correlatedSource

    ...
    <wlevs:adapter id="myHaCorrelatingAdapter" provider="ha-correlating" >
        <wlevs:listener ref="JMSOutboundAdapter"/>
        <wlevs:instance-property name="failOverDelay" value="2000"/>
        <wlevs:instance-property name="correlatedSource" value="clusterCorrelatingOutstream"/>
    </wlevs:adapter>
...

    For more information, see Section 24.2.2.4.1, "Correlating Output Adapter EPN Assembly File Configuration".

  12. If your application is an Oracle Event Processing high availability Type 1 application (the application must generate exactly the same sequence of output events as existing secondaries), configure the warm-up-window-length for the correlating output adapter.

    For more information, see:

  13. Configure the component configuration file to enable session-transacted for both inbound JMS adapters and the outbound JMS adapter as Example 24-43 shows:

    Example 24-43 Inbound and Outbound JMS Adapter Component Configuration File

    <?xml version="1.0" encoding="UTF-8"?>
<wlevs:config 
        xmlns:wlevs="http://www.bea.com/ns/wlevs/config/application"
        xmlns:ha="http://www.oracle.com/ns/cep/config/cluster/">
    ...
    <jms-adapter>
        <name>JMSInboundAdapter</name>
        <jndi-provider-url>t3://localhost:7001</jndi-provider-url>
        <destination-jndi-name>./Topic1</destination-jndi-name>
        <user>weblogic</user>
        <password>weblogic</password>
        <work-manager>JettyWorkManager</work-manager>
        <concurrent-consumers>1</concurrent-consumers>
        <session-transacted>true</session-transacted>
    </jms-adapter>

    <jms-adapter>
        <name>JMSInboundAdapter2</name>
        <jndi-provider-url>t3://localhost:7001</jndi-provider-url>
        <destination-jndi-name>./Topic1</destination-jndi-name>
        <user>weblogic</user>
        <password>weblogic</password>
        <work-manager>JettyWorkManager</work-manager>
        <concurrent-consumers>1</concurrent-consumers>
        <session-transacted>true</session-transacted>
    </jms-adapter>
    ...
    <jms-adapter>
        <name>JMSOutboundAdapter</name>
        <event-type>JMSEvent</event-type>
        <jndi-provider-url>t3://localhost:7001</jndi-provider-url>
        <destination-jndi-name>Topic1</destination-jndi-name>
        <delivery-mode>nonpersistent</delivery-mode>
        <session-transacted>true</session-transacted>
    </jms-adapter>
    ...
</wlevs:config>

  14. Optionally, configure the component configuration file to include the Oracle Event Processing high availability input adapter and correlating output adapter as Example 24-27 shows.

    Example 24-44 High Availability Input and Output Adapter Component Configuration File

    <?xml version="1.0" encoding="UTF-8"?>
<wlevs:config 
        xmlns:wlevs="http://www.bea.com/ns/wlevs/config/application"
        xmlns:ha="http://www.oracle.com/ns/cep/config/cluster/">
    ...
    <ha:ha-inbound-adapter>
        <name>myHaInputAdapter</name>
    </ha:ha-inbound-adapter>
    ...
    <ha:ha-correlating-adapter>
        <name>myHaBroadcastAdapter</name>
        <fail-over-delay>2000</fail-over-delay>
    </ha:ha-correlating-adapter>
    ...
</wlevs:config>

    For more information, see:

  15. Optionally, add an ActiveActiveGroupBean to your EPN to improve scalability.

    For more information, see Section 25.2.2, "Configuring Scalability With the ActiveActiveGroupBean".

  16. Deploy your application to the deployment group you created in step 1.

    For more information, see Section 23.5, "Deploying Oracle Event Processing Applications".

    Oracle Event Processing automatically selects one of the Oracle Event Processing servers as the primary.

24.2.2 Configuring High Availability Adapters

You configure Oracle Event Processing high availability adapters in the EPN assembly file and component configuration files, similar to how you configure other components in the EPN, such as channels or processors. For general information about these configuration files, see:

Note:

After making any Oracle Event Processing high availability configuration changes, you must redeploy your Oracle Event Processing application. See Section 23.5, "Deploying Oracle Event Processing Applications".

This section describes the configurable options for each of the Oracle Event Processing high availability adapters, including:

24.2.2.1 How to Configure the High Availability Input Adapter

The Oracle Event Processing high availability broadcast input adapter is implemented by BroadcastInputAdapter.

This section describes how to configure the Oracle Event Processing high availability input adapter, including:

For more information, see Section 24.1.1.3.1, "High Availability Input Adapter".

24.2.2.1.1 High Availability Input Adapter EPN Assembly File Configuration

The root element for declaring an Oracle Event Processing high availability input adapter is wlevs:adapter with provider element set to ha-inbound as Example 24-45 shows. You specify a wlevs:listener element for the Oracle Event Processing high availability input adapter in the actual input adapter as Example 24-45 shows.

Example 24-45 High Availability Input Adapter EPN Assembly File

<wlevs:adapter id="jmsAdapter" provider="jms-inbound"
    <wlevs:listener ref="myHaInputAdapter"/>      
</wlevs:adapter>

<wlevs:adapter id="myHaInputAdapter" provider="ha-inbound">
    <wlevs:instance-property name="keyProperties" value="id"/>
    <wlevs:instance-property name="timeProperty" value="arrivalTime"/>
    <wlevs:instance-property name="eventType" value="MyEventType"/>
</wlevs:adapter>

<wlevs:channel id="inputChannel" event-type="MyEventType ">
    <wlevs:source ref="myHaInputAdapter"/>
    <wlevs:application-timestamped>
        <wlevs:expression>arrivalTime</wlevs:expression>
    </wlevs:application-timestamped>
</wlevs:channel>

Table 24-3 describes the additional child elements of wlevs:adapter you can configure for an Oracle Event Processing high availability input adapter.

Table 24-3 Child Elements of wlevs:adapter for the High Availability Input Adapter

Child Element Description

wlevs:instance-property

Specify one or more instance-property element name and value attributes as Table 24-4 describes.

Table 24-4 lists the instance properties that the Oracle Event Processing high availability input adapter supports.

Table 24-4 High Availability Input Adapter Instance Properties

Name Value

timeProperty

Specify the name of the event property to which the high availability input adapter assigns a time value.

This is the same property that you use in the wlevs:application-timestamped element of the downstream EPN component to which the high availability input adapter is connected as Example 24-45 shows.

keyProperties

Specify a space delimited list of one or more event properties that the Oracle Event Processing high availability input adapter uses to identify event instances.

If you specify more than one event property, you must specify a keyClass.

Default: all event properties.

keyClass

Specify the fully qualified class name of a Java class used as a compound key.

By default, all JavaBean properties in the keyClass are assumed to be keyProperties, unless the keyProperties setting is used.

eventType

Specify the type name of the events that the Oracle Event Processing high availability input adapter receives from the actual input adapter. This is the same event type that you use in the downstream EPN component to which the high availability input adapter is connected as Example 24-45 shows.

For tuple events, this property is mandatory.

For all other Java class-based event types, this property is optional.

For more information, see Section 9.1, "Overview of Oracle Event Processing Event Types".

24.2.2.1.2 High Availability Input Adapter Component Configuration File Configuration

The root element for configuring an Oracle Event Processing high availability input adapter is ha-inbound-adapter. The name child element for a particular adapter must match the id attribute of the corresponding wlevs:adapter element in the EPN assembly file that declares this adapter as Example 24-50 shows.

Example 24-46 High Availability Input Adapter Component Configuration File

<ha:ha-inbound-adapter>
    <name>myHaInputAdapter</name>
    <heartbeat units="millis">1000</heartbeat>
    <batch-size>10</batch-size>
</ha:ha-inbound-adapter>

Table 24-5 describes the additional child elements of ha-inbound-adapter you can configure for an Oracle Event Processing high availability input adapter.

Table 24-5 Child Elements of ha-inbound-adapter for the High Availability Input Adapter

Child Element Description

heartbeat

Specify the length of time that the Oracle Event Processing high availability input adapter can be idle before it generates a heartbeat event to advance time as an integer number of units.

Valid values for attribute units:

  • nanos: wait the specified number of nanoseconds.

  • millis: wait the specified number of milliseconds.

  • secs: wait the specified number of seconds.

Default: Heartbeats are not sent.

batch-size

Specify the number of events in each timing message that the primary broadcasts to its secondaries. A value of n means that n {key, time} pairs are sent in each message. You can use this property for performance tuning (see Section 27.2.3, "High Availability Input Adapter Configuration"

Default: 1 (disable batching).

24.2.2.2 How to Configure the Buffering Output Adapter

The Oracle Event Processing high availability buffering output adapter is implemented by SlidingWindowQueueTrimmingAdapter.

This section describes how to configure the Oracle Event Processing high availability buffering output adapter, including:

For more information, see Section 24.1.1.3.2, "Buffering Output Adapter".

24.2.2.2.1 Buffering Output Adapter EPN Assembly File Configuration

The root element for declaring an Oracle Event Processing high availability buffering output adapter is wlevs:adapter with provider element set to ha-buffering as Example 24-47 shows.

Example 24-47 Buffering Output Adapter EPN Assembly File

<wlevs:adapter id="mySlidingWindowingAdapter" provider ="ha-buffering">
    <wlevs:listener>
        <bean class="com.bea.wlevs.example.cluster.ClusterAdapterBean"/>
    </wlevs:listener>
    <wlevs:instance-property name="windowLength" value="15000"/>
</wlevs:adapter>

Table 24-6 describes the additional child elements of wlevs:adapter you can configure for an Oracle Event Processing high availability buffering output adapter.

Table 24-6 Child Elements of wlevs:adapter for the Buffering Output Adapter

Child Element Description

wlevs:listener

Specify the regular output adapter downstream from this Oracle Event Processing high availability buffering output adapter.

wlevs:instance-property

Specify one or more instance-property element name and value attributes as Table 24-7 describes.

Table 24-7 lists the instance properties that the Oracle Event Processing high availability broadcast output adapter supports.

Table 24-7 Buffering Output Adapter Instance Properties

Name Value

windowLength

Specify the size of the sliding window as an integer number of milliseconds.

Default: 15000.

24.2.2.2.2 Buffering Output Adapter Component Configuration File Configuration

The root element for configuring an Oracle Event Processing high availability buffering output adapter is ha-buffering-adapter. The name child element for a particular adapter must match the id attribute of the corresponding wlevs:adapter element in the EPN assembly file that declares this adapter as Example 24-48 shows.

Example 24-48 Buffering Output Adapter Component Configuration File

<ha:ha-buffering-adapter >
    <name>mySlidingWindowingAdapter</name>
    <window-length>15000</window-length>
    <warm-up-window-length units="minutes">6</warm-up-window-length>
</ha:ha-buffering-adapter >

Table 24-8 describes the additional child elements of ha-buffering-adapter you can configure for an Oracle Event Processing high availability buffering output adapter.

Table 24-8 Child Elements of ha-buffering-adapter for the Buffering Output Adapter

Child Element Description

window-length

Specify the size of the sliding window as an integer number of milliseconds.

Default: 15000.

warm-up-window-length

Specify the length of time it takes the application to rebuild state after a previously failed secondary restarts or a new secondary is added as an integer number of units.

Valid values for attribute units:

  • seconds: wait the specified number of seconds.

  • minutes: wait the specified number of minutes.

Default: units is seconds.

For more information, see Section 24.1.3.2.5, "Choose an Adequate warm-up-window-length Time".

24.2.2.3 How to Configure the Broadcast Output Adapter

The Oracle Event Processing high availability broadcast output adapter is implemented by class GroupBroadcastQueueTrimmingAdapter.

This section describes how to configure the Oracle Event Processing high availability broadcast output adapter, including:

For more information, see Section 24.1.1.3.3, "Broadcast Output Adapter".

24.2.2.3.1 Broadcast Output Adapter EPN Assembly File Configuration

The root element for declaring an Oracle Event Processing high availability broadcast output adapter is wlevs:adapter with provider element set to ha-broadcast as Example 24-49 shows.

Example 24-49 Broadcast Output Adapter EPN Assembly File

<wlevs:adapter id="myBroadcastAdapter" provider="ha-broadcast">
    <wlevs:listener ref="actualAdapter"/>
    <wlevs:instance-property name="keyProperties" value="time"/>
    <wlevs:instance-property name="monotonic" value="true"/>
</wlevs:adapter>

Table 24-9 describes the additional child elements of wlevs:adapter you can configure for an Oracle Event Processing high availability broadcast output adapter.

Table 24-9 Child Elements of wlevs:adapter for the Broadcast Output Adapter

Child Element Description

wlevs:listener

Specify the regular output adapter downstream from this Oracle Event Processing high availability broadcast output adapter.

wlevs:instance-property

Specify one or more instance-property element name and value attributes as Table 24-10 describes.

Table 24-10 lists the instance properties that the Oracle Event Processing high availability broadcast output adapter supports.

Table 24-10 Broadcast Output Adapter Instance Properties

Name Value

keyProperties

Specify a space delimited list of one or more event properties that the Oracle Event Processing high availability broadcast output adapter uses to identify event instances.

If you specify more than one event property, you must specify a keyClass.

Default: all event properties.

keyClass

Specify the fully qualified class name of a Java class used as a compound key.

By default, all JavaBean properties in the keyClass are assumed to be keyProperties, unless the keyProperties setting is used.

A compound key may be monotonic and may be totalOrder.

monotonic

Specify whether or not the key value is constantly increasing (like a time value).

Valid values are:

  • true: the key is constantly increasing.

  • false: the key is not constantly increasing.

Default: false.

totalOrder

Specify whether or not event keys are unique. Applicable only when instance property monotonic is set to true.

Valid values are:

  • true: event keys are unique.

  • false: event keys are not unique.

Default: true.

24.2.2.3.2 Broadcast Output Adapter Component Configuration File Configuration

The root element for configuring an Oracle Event Processing high availability broadcast output adapter is ha-broadcast-adapter. The name child element for a particular adapter must match the id attribute of the corresponding wlevs:adapter element in the EPN assembly file that declares this adapter as Example 24-50 shows.

Example 24-50 Broadcast Output Adapter Component Configuration File

<ha:ha-broadcast-adapter>
    <name>myBroadcastAdapter</name>
    <trimming-interval units="events">10</trimming-interval>
    <warm-up-window-length units="minutes">6</warm-up-window-length>
</ha:ha-broadcast-adapter>

Table 24-11 describes the additional child elements of ha-broadcast-adapter you can configure for an Oracle Event Processing high availability broadcast output adapter.

Table 24-11 Child Elements of ha-broadcast-adapter for the Broadcast Output Adapter

Child Element Description

trimming-interval

Specify the interval at which trimming messages are broadcast as an integer number of units. You can use this property for performance tuning (see Section 27.2.4, "Broadcast Output Adapter Configuration").

Valid values for attribute units:

  • events: broadcast trimming messages after the specified number of milliseconds.

  • millis: broadcast trimming messages after the specified number of events are processed.

Default: units is events.

warm-up-window-length

Specify the length of time it takes the application to rebuild state after a previously failed secondary restarts or a new secondary is added as an integer number of units.

Valid values for attribute units:

  • seconds: wait the specified number of seconds.

  • minutes: wait the specified number of minutes.

Default: units is seconds.

For more information, see Section 24.1.3.2.5, "Choose an Adequate warm-up-window-length Time".

24.2.2.4 How to Configure the Correlating Output Adapter

The Oracle Event Processing high availability correlating output adapter is implemented by class CorrelatedQueueTrimmingAdapter.

This section describes how to configure the Oracle Event Processing high availability correlating output adapter, including:

For more information, see Section 24.1.1.3.4, "Correlating Output Adapter".

24.2.2.4.1 Correlating Output Adapter EPN Assembly File Configuration

The root element for declaring an Oracle Event Processing high availability correlating output adapter is wlevs:adapter with provider element set to ha-correlating as Example 24-51 shows.

Example 24-51 Correlating Output Adapter EPN Assembly File

<wlevs:adapter id="myCorrelatingAdapter" provider="ha-correlating">
    <wlevs:listener>
        <bean class="com.bea.wlevs.example.cluster.ClusterAdapterBean"/>
    </wlevs:listener>
    <wlevs:instance-property name="correlatedSource" ref="clusterCorrOutstream"/>
    <wlevs:instance-property name="failOverDelay" value="2000"/>
</wlevs:adapter>

Table 24-12 describes the additional child elements of wlevs:adapter you can configure for an Oracle Event Processing high availability correlating output adapter.

Table 24-12 Child Elements of wlevs:adapter for the Correlating Output Adapter

Child Element Description

wlevs:listener

Specify the regular output adapter downstream from this Oracle Event Processing high availability buffering output adapter.

wlevs:instance-property

Specify one or more instance-property element name and value attributes as Table 24-13 describes.

Table 24-13 lists the instance properties that the Oracle Event Processing high availability correlating output adapter supports.

Table 24-13 Correlating Output Adapter Instance Properties

Name Value

correlatedSource

Specify the event source that will be used to correlate against. Events seen from this source will be purged from the trimming queue. Events still in the queue at failover will be replayed.

failOverDelay

Specify the delay timeout in milliseconds that is used to decide how soon after failover correlation should restart.

Default: 0 ms.

24.2.2.4.2 Correlating Output Adapter Component Configuration File Configuration

The root element for configuring an Oracle Event Processing high availability correlating output adapter is ha-correlating-adapter. The name child element for a particular adapter must match the id attribute of the corresponding wlevs:adapter element in the EPN assembly file that declares this adapter as Example 24-52 shows.

Example 24-52 Correlating Output Adapter Component Configuration File

<ha:ha-correlating-adapter>
    <name>myCorrelatingAdapter</name>
    <window-length>15000</window-length>
    <warm-up-window-length units="minutes">6</warm-up-window-length>
</ha:ha-correlating-adapter>

Table 24-14 describes the additional child elements of ha-broadcast-adapter you can configure for an Oracle Event Processing high availability correlating output adapter.

Table 24-14 Child Elements of ha-correlating-adapter for the Correlating Output Adapter

Child Element Description

fail-over-delay

Specify the delay timeout in milliseconds that is used to decide how soon after failover correlation should restart.

Default: 0 ms.

warm-up-window-length

Specify the length of time it takes the application to rebuild state after a previously failed secondary restarts or a new secondary is added as an integer number of units.

Valid values for attribute units:

  • seconds: wait the specified number of seconds.

  • minutes: wait the specified number of minutes.

Default: units is seconds.

For more information, see Section 24.1.3.2.5, "Choose an Adequate warm-up-window-length Time".