22 Understanding Scalability

This chapter describes Oracle CEP components and design patterns that you can use to allow your Oracle CEP application to scale with an increasing event load, including:

Section 22.1, "Scalability Options"
Section 22.2, "Scalability Components"

For more information on how to implement a particular scalability option, see Chapter 23, "Configuring Scalability".

22.1 Scalability Options

Oracle CEP provides options that you can use to allow your Oracle CEP application to scale with an increasing event load.

In general, you can design your application to partition an input event stream and process events in parallel at the point of event ingress, within the Event Processing Network (EPN), or both.

You should plan to use scalability and parallel processing as early in the event processing sequence as possible. For example, parallel process high-volume, low-value events to extract the typically low-volume, high-value events your application depends on.

Oracle CEP provides a variety of scalability components you can use as Section 22.2, "Scalability Components" describes.

22.1.1 Scalability and High Availability

Because scalability often involves deploying an application to multiple servers, it is advantageous to also consider high availability options when designing your Oracle CEP application for scalability.

Input stream partitioning and parallel processing impose important restrictions on application design, such as preserving event order and carefully managing the use of multi-threading.

For more information on high availability options, see:

22.2 Scalability Components

Oracle CEP provides the following components that you can use to improve the scalability of your Oracle CEP applications:

Section 22.2.1, "EventPartitioner"
Section 22.2.2, "ActiveActiveGroupBean"

22.2.1 EventPartitioner

A com.bea.wlevs.channel.EventPartitioner provides a mechanism for partitioning events on a channel across its output event sinks as Figure 22-1 shows.

Figure 22-1 Event Partitioner EPN

Description of "Figure 22-1 Event Partitioner EPN"

This section describes:

Section 22.2.1.1, "EventPartitioner Implementation"
Section 22.2.1.2, "EventPartitioner Load Balancing"
Section 22.2.1.3, "EventPartitioner Initialization"
Section 22.2.1.4, "EventPartitioner Threading"
Section 22.2.1.5, "EventPartitioner Restrictions"

For more information, see Section 23.1, "Configuring Scalability With a Channel EventPartitioner".

22.2.1.1 EventPartitioner Implementation

Oracle CEP provides a default event property-based EventPartitioner that you can configure a channel to use.

When you configure a channel to use the default EventPartitioner, you specify the name of an event property by which the channel partitions events. The default EventPartitioner calculates a hash key using the event property value's Object.hashCode() as input to an internal hash function. The hashkey % number-of-listeners is used to calculate which listener will receive the event. This algorithm is based on the same algorithm used by HashMap to calculate in which bucket to place a new item. In practice, this means events with the same event property value are sent to the same listener.

Note:

The default event property-based EventPartitioner does not dispatch in Round Robin fashion.

Optionally, you can create your own event partitioner instance and configure a channel to use it instead to customize how events are dispatched to the channel's listeners.

For more information, see:

22.2.1.2 EventPartitioner Load Balancing

When using an event partitioner channel, if you want to perform load balancing, then each listener must be identical.

Otherwise, listeners need not be identical.

22.2.1.3 EventPartitioner Initialization

By default, the Oracle CEP server initializes each event partitioner on deployment and will re-initialize event partitioners on re-deployment by invoking the EventPartitioner method activateConfiguration is before ActivatableBean.afterConfigurationActive and before your EventPartitioner class's partition method is invoked.

22.2.1.4 EventPartitioner Threading

Table 22-1 lists the threading options you can use with an event partitioner channel.

Table 22-1 Event Partitioner Channel Threading Options

Threads Allocated In Description When to Use

Threads Allocated In	Description	When to Use
Channel	Channel `max-threads` set to the number of listeners.	Usually acceptable if conversion of the external message format into the internal event format is inexpensive. Lets the multithreading be controlled at the channel granularity. Some channels may require a higher number of threads than others due to differences in volume.
Adapter	Channel `max-threads` set to 0. Implement a multi-threaded adapter with at least on thread per partition listener.	Usually preferable if conversion of the external message format into the internal event format is expensive. This approach is best when the adapter is multithreaded and the inbound event rate is high enough that the adapter becomes a bottleneck unless multiple threads can be used to scale the inbound processing.

Channel

Channel max-threads set to the number of listeners.

Usually acceptable if conversion of the external message format into the internal event format is inexpensive.

Lets the multithreading be controlled at the channel granularity. Some channels may require a higher number of threads than others due to differences in volume.

Adapter

Channel max-threads set to 0.
Implement a multi-threaded adapter with at least on thread per partition listener.

Usually preferable if conversion of the external message format into the internal event format is expensive.

This approach is best when the adapter is multithreaded and the inbound event rate is high enough that the adapter becomes a bottleneck unless multiple threads can be used to scale the inbound processing.

Note:

In either approach, event order cannot be guaranteed. This is true whenever multiple threads are used.

22.2.1.5 EventPartitioner Restrictions

When configuring a channel to use an event partitioner, consider the following restrictions:

Batching is not supported when you configure a channel with an event partitioner.

For more information, Section 9.1.6, "Batch Processing Channels".

22.2.2 ActiveActiveGroupBean

Using the com.oracle.cep.cluster.hagroups.ActiveActiveGroupBean, you can partition an incoming JMS stream in Oracle CEP applications by utilizing the notification groups that the ActiveActiveGroupBean creates.

You add an ActiveActiveGroupBean to your EPN assembly file as Example 22-1 shows.

Example 22-1 ActiveActiveGroupBean bean Element

<bean id="clusterAdapter" class="com.oracle.cep.cluster.hagroups.ActiveActiveGroupBean">
</bean>

By default, the ActiveActiveGroupBean creates notification groups named:

ActiveActiveGroupBean_X

Where X is a string.

At runtime, the ActiveActiveGroupBean scans the existing groups defined on the Oracle CEP server and applies a default pattern match of:

ActiveActiveGroupBean_\\w+

When it finds a match, it creates a notification group of that name.

Optionally, you can define your own cluster group pattern match as Section 23.2.3, "How to Configure the ActiveActiveGroupBean Group Pattern Match" describes.

This section describes:

Section 22.2.2.1, "Scalability in an Oracle CEP Application Using the ActiveActiveGroupBean Without High Availability"
Section 22.2.2.2, "Scalability in an Oracle CEP Application Using the ActiveActiveGroupBean With High Availability"

For more information, see:

22.2.2.1 Scalability in an Oracle CEP Application Using the ActiveActiveGroupBean Without High Availability

You can use the ActiveActiveGroupBean to partition an incoming JMS event stream by selector in an Oracle CEP application that is not configured for high availability.

Consider the multi-server domain that Figure 22-2 shows.

Figure 22-2 Oracle CEP ActiveActiveGroupBean Without High Availability

Description of "Figure 22-2 Oracle CEP ActiveActiveGroupBean Without High Availability"

In this scalability scenario, you define a cluster group in the Oracle CEP server config.xml on each server (ActiveActiveGroupBean_group1 on Host 1, ActiveActiveGroupBean_group2 on Host 2, and so on) and add an instance of the ActiveActiveGroupBean to your Oracle CEP application to define notification groups based on these cluster groups.

Each notification group is bound to a different JMS selector. The component configuration file in your Oracle CEP application contains the same jms-adapter configuration as Example 22-2 shows.

Example 22-2 Common jms-adapter Selector Definitions

<jms-adapter>
    <message-selector>${CONDITION}</message-selector>
    <bindings>
        <group-binding group-id="ActiveActiveGroupBean_group1">
            <param id="CONDITION">acctid > 400</param>
        </group-binding>
        <group-binding group-id="ActiveActiveGroupBean_group2">
            <param id="CONDITION">acctid BETWEEN 301 AND 400</param>
        </group-binding>
        <group-binding group-id="ActiveActiveGroupBean_group3">
            <param id="CONDITION">acctid BETWEEN 201 AND 300</param>
        </group-binding>
        <group-binding group-id="ActiveActiveGroupBean_group4">
            <param id="CONDITION">acctid <= 200</param>
        </group-binding>
     </bindings>
</jms-adapter>

At runtime, the ActiveActiveGroupBean instance in each Oracle CEP application instance on each Oracle CEP server finds its ActiveActiveGroupBean_ cluster group and creates a notification group based on it. The Oracle CEP application then configures itself with the message-selector that corresponds to the group-id that matches that notification group. This partitions the JMS topic so that each instance of App1 processes a subset of the total number of messages in parallel.

Note:

Within each instance of App1, you could further increase parallel processing by configuring an event partitioner channel as Section 22.2.1, "EventPartitioner" describes.

For more information, see Section 23.2.1, "How to Configure Scalability in a JMS Application Without Oracle CEP High Availability".

22.2.2.2 Scalability in an Oracle CEP Application Using the ActiveActiveGroupBean With High Availability

In addition to partitioning an incoming JMS event stream by selector, you can also use the ActiveActiveGroupBean to configure two or more Oracle CEP servers to function as a single, high availability unit.

Consider the multi-server domain with an Oracle CEP high availability application deployed to it that Figure 22-3 shows.

Figure 22-3 Oracle CEP ActiveActiveGroupBean With High Availability

Description of "Figure 22-3 Oracle CEP ActiveActiveGroupBean With High Availability"

In this scenario, you create the same ActiveActiveGroupBean_ cluster group on Host 1 and Host 2 (ActiveActiveGroupBean_group1) and the same ActiveActiveGroupBean_ cluster group on Host 3 and Host 4 (ActiveActiveGroupBean_group2).

At runtime, the ActiveActiveGroupBean instance in each Oracle CEP application instance on each Oracle CEP server finds its ActiveActiveGroupBean_ cluster group and creates a notification group based on it. Both Host 1 and Host 2 belong to one notification group (ActiveActiveGroupBean_group1) and both Host 3 and Host 4 belong to another notification group (ActiveActiveGroupBean_group2) .

Each Oracle CEP application then configures itself with the message-selector that corresponds to the group-id that matches that notification group. This partitions the JMS topic so that each instance of App1 processes a subset of the total number of messages in parallel.

When more than one Oracle CEP server belongs to the same notification group, the ActiveActiveGroupBean ensures that only the primary server in each notification group outputs events. Within a given notification group, should the primary server go down, then an Oracle CEP high availability fail over occurs and one of the secondary servers in that notification group is declared the new primary and resumes outputting events according to the Oracle CEP high availability quality of service you configure.

Note:

Within each instance of App1, you could further increase parallel processing by configuring an event partitioner channel as Section 22.2.1, "EventPartitioner" describes.

For more information, see Section 23.2.2, "How to Configure Scalability in a JMS Application With Oracle CEP High Availability".