Clustered Deployment

Distributed deployment of CEP enables it to achieve High Availability, and Scalability in terms of memory.

There are two modes of distributed deployment for CEP which are as follows,

Distributed Cache Mode Deployment

WSO2 CEP with Siddhi uses Hazelcast to achieve distributed processing. To enable distributed processing all CEP servers has to be deployed in the same Local Area Network, this enables all the Hazelcast instances of CEP to identify each other using multicast and create an in-memory cluster for supporting distributed processing.

In WSO2 CEP, distributed processing can be enabled at per bucket level where by only those identified buckets will use the distributed cache for processing,

Follow below steps to enable distributed processing to a bucket.

Create distributed CEP buckets with the following properties
Warning

Not following the below conventions will lead to unpredictable results!
- All bucket has to have the same Bucket Name
- All should use Siddhi CEP back end runtime engine
- Buckets has to have the following Backend Runtime Configuration
```
Backend Runtime Configuration

Persistence snapshot time interval in minutes	: 0
Enable distributed processing			: true
```
  These can be added to the configuration file as below.
```
<bucket name="FraudAnalyzer" xmlns="http://wso2.org/carbon/cep">
    ...
    <engineProviderConfiguration engineProvider="SiddhiCEPRuntime">
        <property name="siddhi.persistence.snapshot.time.interval.minutes">0</property>
        <property name="siddhi.enable.distributed.processing">true</property>
    </engineProviderConfiguration>
    ...
</bucket>
```
- All buckets should have identical queries (Queries has to use same stream names, same type of events and queries in all the buckets have to be in the same order)
- But the input topics need NOT to be the same, by using different input topics users can distribute load when publishing to CEP.
Deploy the buckets to CEP nodes.

Follow the sample Distributed Purchase Analyzer Sample and Fraud Analyzer step by step guide to better understand this functionality

Persistence Mode Deployment

Using persistence mode enables CEP Queries to span lifetimes much greater than server uptime. This is achieved by taking periodic snapshots and storing all state information & windows in a scalable persistence store. In CEP we use Apache Cassandra as the scalable persistence store in order to achieve high scalability and low latency when persisting data. In this mode if server crashes the same server or another CEP server with the same bucket connected to the same Cassandra Data Store can be restored from the last available snapshot.

WSO2 CEP persistence mode processing can be enabled at per bucket level where by only those identified buckets will persist bucket states,

Follow below steps to enable persistence mode processing to a bucket.

Create CEP bucket with the following properties

Bucket has to have the following Backend Runtime Configuration

Backend Runtime Configuration

Persistence snapshot time interval in minutes	: 5 (Any positive long value)
Enable distributed processing			: false

These can be added to the configuration file as below.

<bucket name="AllStocksAnalyzer" xmlns="http://wso2.org/carbon/cep">
    ...
    <cep:engineProviderConfiguration engineProvider="SiddhiCEPRuntime">        
        <cep:property name="siddhi.persistence.snapshot.time.interval.minutes">5</cep:property>
        <cep:property name="siddhi.enable.distributed.processing">false</cep:property>
    </cep:engineProviderConfiguration>
    ...
</bucket>

In order to persist states at shout down use graceful shout down from the CEP server

The steps are as follows :

- - Sign In. Enter your user name and password to log on to the Complex Event Processor Management Console.
  - Click on "Shutdown/Restart Server" menu item under Manage section of the left panel
    This will redirect to the Shutdown/Restart Server page.
  - Click on "Graceful Restart" and click "Yes" to conform Server restart when prompted.