ApplicationDefinition

Application Definition

As we have seen, Dempsy needs some minimal description of an application. With "Dynamic Topology" this description itself doesn't need to be centralized. In the examples we have seen to date the Application Definition described all of the MessageProcessors that participate in an application. For many, if not most applications, this is a good way to go since everything is defined in one place.

Let's review. In the Word Count example the application definition fully describes the application by listing which message processors participate in the application. Note, this configuration does NOT describe the topology (which message processors send messages to which other message processors). Again, that information is discovered at runtime and so the order of the ClusterDefinitions below makes no difference.

<beans>
  <bean class="com.nokia.dempsy.config.ApplicationDefinition">
    <constructor-arg value="word-count" />
    <property name="clusterDefinitions">
      <list>
        <bean class="com.nokia.dempsy.config.ClusterDefinition">
          <constructor-arg value="adaptor"/>
          <property name="adaptor">
            <bean class="com.nokia.dempsy.example.userguide.wordcount.WordAdaptor" />
          </property>
        </bean>
        <bean class="com.nokia.dempsy.config.ClusterDefinition">
          <constructor-arg value="mp"/>
          <property name="messageProcessorPrototype">
            <bean class="com.nokia.dempsy.example.userguide.wordcount.WordCount"/>
          </property>
        </bean>
      </list>
    </property>
  </bean>
</beans>

Notice, an ApplicationDefinition contains ClusterDefinitions and, remembering our Terminology, a Cluster is the set of all message processors of a particular type that are all participating in the same step of an application.

There are several parameters that can be set for both the ApplicationDefinition and the ClusterDefinition. All of the ApplicationDefinition parameters allow for the defaulting of Cluster specific settings and can be redefined or overridden at the cluster level using the ClusterDefinition. The ApplicationDefinition parameters include:

1. serializer - Optional - You can set the serialization scheme for the transferring of messages between message processors. Out of the box, Dempsy comes with two serializers that can be used here. One supports straightforward java serialization and one supports Kryo. Kryo is the default but should be tuned for production applications. See the section on [Serialization] for how to correctly tune Kryo within Dempsy. Custom serialization can also be defined. See the section on Framework Development and specifically the section on the Serialization Api.
2. statsCollectorFactory - Optional - This setting provides for either the complete override the monitoring back-end, or the fine tuning of the main out-of-the-box implementation. The main implementation is very powerful and so the main use of this setting will be to fine tune the monitoring parameters. For information on how to completely replace the monitoring see the section on the Monitoring Api as part of Framework Development. See the section on Monitoring Configuration for details on how to tune the Dempsy statistics collector.
3. executor - Optional - This may change prior to a 1.0 release. Dempsy provides for the ability to tune, or completely redefine, the default threading model for processing. To understand how to replace the threading model, see the section on the Executor Api as part of Framework Development. To tune the existing implementation see the section on Executor Configuration.

Each of the above parameters can be overridden in the ClusterDefinition. In addition, the ClusterDefinition provides for the setting of the following:

1. adaptor - Required either adaptor or messageProcessorPrototype - Setting the Adaptor defines a special type of cluster that defines the source for streaming data. The object provided must be an instance of the Adaptor interface. See the Adaptors section of the Simple Example and the api docs for the Adaptor interface for more information.
2. adaptorDaemon - Optional - this is a boolean property that identifies whether or not the thread that the Adaptor runs in should be a daemon thread. The default is false. It's really not a good idea to use this parameter as it tells Dempsy to ignore the shutting down of the Adaptor. Ideally an adaptor should shutdown cleanly in response to a stop. This property is ignored if the ClusterDefninition doesn't have the adaptor set.
3. messageProcessorPrototype - Required either adaptor or messageProcessorPrototype - This is how a prototype for the message processor is provided to the cluster. The object provided must be annotated with the @MessageProcessor annotation. See the Message Processor Prototype section of the Simple Example and the api docs for the @MessageProcessor annotation for more information.
4. evictionTimePeriod and evictionTimeUnit - Optional - When a message processor is evictable these properties allow for the tuning of the frequency of eviction checking. If one is set, they should both be set. The default is 600 seconds (10 minutes). The time unit is a instance of the enum java.util.concurrent.TimeUnit. If the message processor isn't evictable then setting these properties has no effect.
5. outputExecutor - Required if the message processor needs to run @Output cycles - This property is used to set the scheme for invoking an @Output cycle. See the section in the Simple Example on Non-stream Driven Message Processor Output for more information. Especially the Advanced Options section. This setting can be used to define new schemes following the details in the section on the Output Executor Api as part of Framework Development.

Next section: Serialization Configuration and Tuning