...

There are many configuration knobs that can be used to customize the store's behavior and performance. See DDL Config Reference for a listing of configuration knobs for storage.

Unsolicited Senders

For applications that use state replication with an unsolicited sender (i.e. those not done from a message handler)

...

<app name="processor" mainClass="com.sample.Application">
  ...
  <replicateUnsolicitedSends>true<replicateUnsolicitedSends
</app>

...

Creation of Application State

Application state is always created by the AEP engine and is created in one of three different ways:

1. By a primary engine when it receives the first message of a flow, in which case it utilizes the application provided IApplicationStateFactory.
2. By a backup engine when application state is replicated from a primary.
3. Explicitly by an application on an AepMessagingPrestartEvent handler.

Two constraints need to be met when the state is created explicitly by the application.

1. For performance reasons, the state creation is not thread safe. Thus, the state must be created before the engine's messaging has been started.
2. The state needs to be created after the engine has bound to the applications's ODS store. This needs to be done so that the created state is attached to the opened store.

The first constraint implies that the state must be created before the engine has started messaging. The second constraint implies that the state needs to be created during or after start (since the engine opens the store during start()) i.e. the only time the state can be explicitly created by the application is between start() and the receipt of the messaging started event. The messaging prestart event is such a point in the flow.

Interacting With Application State

From a message handler

The below snippet comes from the Enricher message handler. With a message handler, application state should be retrieved using the Engine's getApplicationState(MessageView) accessor, which retrieves the state associated with the message's flow. In the Ticker sample, the flow is defined by the hashCode of the symbol and is set by the Feeder. Flows define the order in which messages are processed in the system. Flows essentially partition traffic into ordered parallel processed streams and, therefore, enable parallelized, concurrent message processing.
Under the covers, the Engine ensures that both messages and state are replicated to the backup to prevent loss or duplication in the event of a failure.

//to the enriched channel with a trend.
ApplicationState state = _engine.getApplicationState(tick); 
state.setSno(state.getSno() + 1); 
state.getTickHistory().add(tick); 
.. 
_engine.sendMessage({_}enrichChannel, enriched); 
//Clear out older entries:
if(state.getTickHistory().size() > HISTORY_SIZE) {
    state.getTickHistory().remove();
}

Unsolicited Sends

The Feeder operates slightly differently. Because it is the origin point of the traffic, it can't retrieve its state from the Engine using a MessageView, but as mentioned previously, Creation of State can only be done from an engine thread. It must therefore create its state from within an AepMessagingPrestartEvent handler. If the Feeder were to operate with multiple flows (and consequently multiple application state instances, it would need to create them all here.

// The messaging prestart event
@EventHandler
public void onMessagingPrestart( AepMessagingPrestartEvent evt) {
	//In a more complex application one might futher initialize
    //The state prior to returning it:
    _state = _engine.getApplicationState(symbol.hashCode()); 
}

...

Limitations and Upcoming Enhancements

See State Graph Limitations for a discussion of current state graph limitations. 

...