| Oracle® Complex Event Processing Developer's Guide 11g Release 1 (11.1.1) for Eclipse Part Number E14301-03 |
|
|
View PDF |
| Oracle® Complex Event Processing Developer's Guide 11g Release 1 (11.1.1) for Eclipse Part Number E14301-03 |
|
|
View PDF |
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:
For more information on how to implement a particular scalability option, see Chapter 19, "Configuring Scalability".
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 18.2, "Scalability Components" describes.
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:
Oracle CEP provides the following components that you can use to improve the scalability of your Oracle CEP applications:
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 18-1 shows.
Example 18-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 19.2.3, "How to Configure the ActiveActiveGroupBean Group Pattern Match" describes.
This section describes:
For more information, see:
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 18-1 shows.
Figure 18-1 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 18-2 shows.
Example 18-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 18.2.2, "Event Partitioner Channel" describes.For more information, see Section 19.2.1, "How to Configure Scalability in a JMS Application Without Oracle CEP 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 18-2 shows.
Figure 18-2 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 18.2.2, "Event Partitioner Channel" describes.For more information, see Section 19.2.2, "How to Configure Scalability in a JMS Application With Oracle CEP High Availability".
An event partitioner provides a mechanism for partitioning events on a channel across its output event sinks as Figure 18-3 shows.
When you configure a channel to use an event partitioner, each time an incoming event arrives, the channel selects a listener and dispatches the event to that listener instead of broadcasting each event to every listener.
In this architecture, each listener must be identical.
When configuring a channel to use an event partitioner, consider the following restrictions:
You can only use an event partitioner with a channel that you configure in pass-through mode. That is, the channel max-threads attribute must be set to 0.
Batching is not supported when you configure a channel with an event partitioner.
For more information, see Section 19.1, "How to Configure Scalability With an Event Partitioner Channel".
|
 Copyright © 2007, 2010, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
