This section includes topics relating to the configuration for applications using Apama’s correlator-integrated messaging for JMS. It covers configuration files, configuration objects, and the configuration properties that can be set when developing your applications.
The correlator-integrated messaging for JMS configuration consists of a set of XML files and .properties files.
A correlator that supports JMS has the following two files:
jms-global-spring.xmljms-mapping-spring.xmlIn addition, for each JMS connection added to the configuration, there will be an additional XML and .properties file :
*connectionId*-spring.xml*connectionId*-spring.propertiesWhen the correlator is started with the --jmsConfig *configDir* option (see also Starting the correlator), it will load all XML files matching *-spring.xml in the specified configuration directory, and also all *.properties files in the same directory. (Note, the correlator will not start unless the specified directory contains at least one configuration file.)
Note:
When the correlator is started, any properties that are specified with the --config *file* or -D*key*=*value* option take precedence and override the properties defined in a *connectionId*-spring.properties file. An INFO message is then logged for all Spring properties that are being ignored.
Global configuration that is shared across all a correlator’s connections is stored in jms-global-spring.xml, the rules for mapping between JMS messages and Apama events are stored in jms-mapping-spring.xml, and the *connectionId*-spring.xml files contain the configuration for each JMS broker connection added to the configuration. Each XML file can contain ${...} property placeholders, whose values come from the *.properties files. This provides a way for the configuration to be defined once in the XML files, then customized for development, UAT, and different deployment scenarios by creating separate copies of the .properties files.
When using Apama in Apama Plugin for Eclipse, all these files are generated automatically. A new *connectionId*-spring.xml and *connectionId*-spring.properties file is created when the JMS Configuration Wizard is used to add a JMS connection, and the most commonly used settings can be changed at any time using the correlator-integrated messaging for JMS instance editor window (which rewrites the .properties file whenever the configuration is changed). Apama Plugin for Eclipse makes it easy to set and edit basic configuration options with the adapter editor. In addition, the jms-global-spring.xml and *connectionId*-spring.xml files can be edited manually in Apama Plugin for Eclipse to customize more advanced configuration aspects such as advanced sender/receiver settings, logging of messages, etc. To edit the XML, open the correlator-integrated messaging for JMS editor and click on the Advanced tab; the various configuration files can be accessed through the hyperlinks on this tab. Once the editor for an XML file has been opened, you can switch between the Design and Source views using the tabs at the bottom of the editor window.
Note that unlike the other XML files, Apama does not support manual editing of the jms-mapping-spring.xml file in this release, and the format of that file may change at any time without notice. We recommend using Apama Plugin for Eclipse for all mapping configuration tasks.
The correlator-integrated messaging for JMS configuration files use the Spring XML file format, which provides an open-source framework for flexibly wiring together the difference parts of an application, each of which is represented by a bean. Each bean is configured with an associated set of properties, and has a unique identifier which can be specified using the id= attribute.
For example:
<bean id="globalReceiverSettings"
class="com.apama.correlator.jms.config.JmsReceiverSettings">
<property name="logJmsMessages" value="true"/>
<property name="logProductMessages" value="false"/>
</bean>
Or:
<jms:receiver id="myReceiver1">
<property name="destination" value="queue:SampleQ1"/>
</jms:receiver>
It is not necessary to have a detailed knowledge of Spring to configure correlator-integrated messaging for JMS, but some customers may wish to explore the Spring 3.0.5 documentation to obtain a deeper understanding of what is going on and to leverage some of the more advanced functionality that Spring provides.
The key beans making up the Apama configuration are jms:connection, jms:receiver and jms:sender, plus additional beans that are usually stored in the jms-global-spring.xml file and shared across all configured connections, such as the reliable receive database and the advanced sender/receiver settings beans.
All receiver, sender, connection, and other configuration beans have an “id=” attribute that specifies a unique identifier. These identifiers are used in log messages, when monitoring status from EPL applications, and, when necessary, for references between different Spring beans in the XML configuration files. It is important that all identifiers are completely unique, for example the same ID cannot be used for senders and receivers in different connections, or for both a sender and a receiver, even if they located in different XML files.
Most bean properties have primitive values (such as string, number, boolean) which are set like this:
<property name="propName" value="my value"/>
However, there are also a few properties that reference other beans, such as the reliableReceiveDatabase property on jms:connection and the receiverSettings property on jms:receiver. These property values can be set by specifying the ID of a top-level bean like this (where it is assumed that globalReceiverSettings is the ID of a JmsReceiverSettings bean):
<property name="receiverSettings" ref="globalReceiverSettings"/>
Any top-level bean may be referenced in this way, that is, any bean that is a child of the <beans> element and not nested inside another bean. Referencing a bean that is defined in a different configuration file is supported, and the jms-global-spring.xml file is intended as a convenient place to store top-level beans that should be shared across many different JMS connections.
Instead of referencing a shared bean, it is also possible to configure a bean property by creating an “inner” configuration bean nested inside the property value like this:
<property name="receiverSettings">
<bean class="com.apama.correlator.jms.config.JmsReceiverSettings">
<property name="logJmsMessages" value="true"/>
</bean>
</property>
(Note, advanced users may want to exploit Spring’s property inheritance by using the parent= attribute on an inner bean to inherit most properties from a standard top-level bean while overriding some specific subset of properties or by type-based “auto-wiring” - any non-primitive property of jms:connection/receiver/sender for which no value is explicitly set will implicitly reference a top-level bean of the required type. This is how jms:connection beans get a reference to the reliableReceiveDatabase and defaultSender/ReceiverSettings beans. Most configuration can just ignore this detail and use the automatically wired property values, and the bean representing the Apama-provided mapper, but if desired the defaults for individual connections/senders/receivers can be customized independently of each other by specifying the property values explicitly.)
For simple cases where detailed configuration of receivers is not required, it is possible to configure static receivers using a simple semicolon-delimited list of JMS destinations, for example:
<property name="staticReceiverList"
value="topic:MyTopic;jndi:/sample/some-jndiqueuename" />
The staticReceiverList bean property is represented by a placeholder in the *connectionId*-spring.properties file, and can be edited using Apama Plugin for Eclipse.
For more advanced receiver configuration, it is necessary to edit the *connectionId*-spring.xml file manually, and provide a list of jms:receiver beans as the value of the staticReceivers property:
<property name="staticReceivers">
<list>
<jms:receiver id="myReceiver1">
<property name="destination"
value="queue:SampleQ1"/>
</jms:receiver>
<jms:receiver id="myReceiver2">
<property name="destination"
value="jndi:/sample/my-jndi-topic-name"/>
<property name="durableTopicSubscriptionName"
value="MyTopicSubscription"/>
</jms:receiver>
</list>
</property>>
Senders may be configured in the same way, for example:
<property name="staticSenders">
<!-- each static sender results in a correlator channel
called "jms:senderId" -->
<list>
<jms:sender id="MyConnection-default-sender">
</jms:sender>
<jms:sender id="myReliableSender">
<property name="senderReliability" value="EXACTLY_ONCE"/>
</jms:sender>
<jms:sender id="myUnreliableSender">
<property name="senderReliability" value="BEST_EFFORT"/>
</jms:sender>
</list>
</property>
If a sender list is not explicitly configured, a single sender with ID *connectionId*-default-sender will be created.
This topic lists the various configuration objects (beans) and the supported properties for each bean.
See also Using custom EL mapping extensions.
This bean defines the information needed to establish a JMS Connection to a single JMS broker instance. Its required properties are: connectionFactory or connectionFactory.jndiName, and (if JNDI is used to locate the connection factory), jndiContext.
Example:
<jms:connection id="MyConnection">
<property name="staticReceiverList"
value="${staticReceiverList.MyConnection}" />
<property name="defaultReceiverReliability"
value="${defaultReceiverReliability.MyConnection}"/>
<property name="defaultSenderReliability"
value="${defaultSenderReliability.MyConnection}"/>
<property name="connectionFactory.jndiName"
value="${connectionFactory.jndiName.MyConnection}" />
<property name="jndiContext.environment">
<value>
${jndiContext.environment.MyConnection}
</value>
</property>
<property name="connectionAuthentication.username"
value="${connectionAuthentication.username.MyConnection}" />
<property name="connectionAuthentication.password"
value="${connectionAuthentication.password.MyConnection}" />
</jms:connection>
Supported properties:
connectionFactory.jndiName - the JNDI lookup name for the ConnectionFactory object that should be used for this jms:connection.connectionFactory - a JMS provider bean that implements the JMS ConnectionFactory interface, if the ConnectionFactory is to be instantiated directory by the Spring framework (rather than using JNDI to lookup the ConnectionFactory). The bean value that is provided will usually required properties and/or constructor arguments to be specified in order to fully initialize it.connectionAuthentication.username - the name of the user/principal to be used for the JMS connection (note that this is often different from the username/password needed to login to the JNDI server, which is part of the JNDI environment configuration). Default value is “”.connectionAuthentication.password - the password/credentials to be used for the JMS connection.jndiContext.environment - the set of properties that specify the environment for initializing access to the JNDI store. Typically includes some standard JNDI keys such as java.naming.factory.initial, java.naming.provider.url, java.naming.security.principal and java.naming.security.credentials, and maybe also some provider-specific keys. The usual way to specify a properties map value is *key*=*value* entries delimited by newlines and surrounded by the <value> element, for example, <property name="jndiContext.environment"><value>...</value><</property>.clientId - the JMS client ID which uniquely identifies each connected JMS client to the broker. Default value is "" although some JMS providers may require this to be set, especially when using durable topics.defaultReceiverReliability - the Apama reliability mode to use for all this connection’s receivers unless overridden on a per-receiver basis; valid values are BEST_EFFORT, AT_LEAST_ONCE, EXACTLY_ONCE, APP_CONTROLLED. Default value is BEST_EFFORT.defaultSenderReliability - the Apama reliability mode to use for all this connection’s senders unless overridden on a per-sender basis; valid values are BEST_EFFORT, AT_LEAST_ONCE, EXACTLY_ONCE. Default value is BEST_EFFORT.staticReceiverList - a list of destinations to receive from, delimited by semi-colons. Each destination must begin with “queue:”, “topic:” or “jndi:”. This property provides a simple way to add static receivers when the more advanced configuration options provided by the staticReceivers property are not needed. staticReceiverList receivers are always added in addition to any receivers specified by staticReceivers. The staticReceiverList property cannot contain duplicate destination entries (see the staticReceivers property if this is required). Default value is “”.staticReceivers - a list of jms:receiver beans specifying JMS receivers to create for this connection. The jms:receiver elements are wrapped in a <list> element, for example, <property name="staticReceivers"><list>...</list></property>. Default value is an empty list.staticSenders - a list of sender beans specifying JMS senders to create for this connection. The jms:sender elements are wrapped in a <list> element, for example, <property name="staticSenders"><list>...</list></property>. Default value is a single sender called “default”.defaultReceiverSettings (advanced users only) - a reference to a JmsReceiverSettings bean, which provides access to advanced settings that are usually shared across all configured receivers for this connection. Default value is a reference to the JmsReceiverSettings bean instance defined in the jms-global-spring.xml file (this uses Spring’s byType auto-wiring; if multiple top-level JmsReceiverSettings beans exist in the configuration then the reference must be specified explicitly in each jms:connection).defaultSenderSettings (advanced users only) - a reference to a JmsSenderSettings bean, which provides access to advanced settings that are usually shared across all configured senders for this connection. Default value is a reference to the JmsSenderSettings bean instance defined in the jms-global-spring.xml file (this uses Spring’s byType auto-wiring; if multiple top-level JmsSenderSettings beans exist in the configuration then the reference must be specified explicitly in each jms:connection).reliableReceiveDatabase (advanced users only) - a reference to a ReliableReceiveDatabase bean, which is required for implementing the AT_LEAST_ONCE or EXACTLY_ONCE reliability modes for any receivers added to this jms:connection. Default value is a reference to the single DefaultReliableReceiveDatabase bean instance defined in the jms-global-spring.xml file (this uses Spring’s byType auto-wiring; if multiple top-level DefaultReliableReceiveDatabase beans exist in the configuration then the reference must be specified explicitly in each jms:connection). The only reason for changing this property would be to use separate databases or different JMS connections which could in some advanced cases provide a performance advanced, depending on the application architecture and the configuration of the jms:connection and disk hardware.connectionRetryIntervalMillis - Specifies how long to wait between attempts to establish the JMS connection. Default value is 1000 ms.receiverMapper - points to a custom mapper. Typically you use a ref="beanid" attribute to do this. If this property is not specified, the default is that the connection uses the Apama-provided mapper, assuming it is the only mapper defined in the configuration.senderMapper - points to a custom mapper. Typically you use a ref="beanid" attribute to do this. If this property is not specified, the default is that the connection uses the Apama-provided mapper, assuming it is the only mapper defined in the configuration.This bean defines a single-threaded context for receiving events from a single JMS destination. Its only required property is “destination”.
Example:
<jms:receiver id="myReceiver">
<property name="destination" value="topic:SampleT1"/>
</jms:receiver>
Supported properties:
destination - the JMS queue or topic to receive from. Must begin with the prefix “queue:”, “topic:” or “jndi:”. A JMS queue or topic name can be specified with the “queue:” or “topic:” prefixes, or if the queue or topic should be looked up using a JNDI name then the “jndi:” prefix should be used instead.receiverReliability - the Apama reliability mode to use when JMS messages are received; valid values are BEST_EFFORT, AT_LEAST_ONCE, EXACTLY_ONCE, APP_CONTROLLED. Default value is provided by the parent jms:connection’s defaultReceiverReliability setting.durableTopicSubscriptionName - if specified, a durable topic subscriber will be created (instead of a queue/topic consumer), and registered with the specified subscription name. Default value is “”, which means do not create a durable topic subscription. Note that some providers will require the connection’s clientId property to be specified when using durable topics.messageSelector - a JMS message selector string that will be used by the JMS provider to filter the messages pulled from the queue or topic by this receiver, based on the header and/or property values of the messages. Default value is "" which means that no selector is in operation and all messages will be received. Message selectors can be used to partition the messages received by multiple receivers on the same queue or durable topic. The JMS API documentation describes the syntax of message selectors in detail; a simple example selector is “JMSType = 'car' AND color = 'blue' AND weight > 2500”.noLocal - an advanced JMS consumer parameter that prevents a connection’s receivers from seeing messages that were sent on the same (local) JMS connection. Default value is false.dupDetectionDomainId - an advanced Apama setting for overriding the way receivers are grouped together for duplicate detection purposes when using EXACTLY_ONCE receive mode. Set this to the same string value for a set of receivers to request detection of duplicate uniqueMessageIds across all the messages from those receivers. Default value is “<connectionId>:<destination>” (that is, look for duplicates across all receivers for the same queue/topic only within the samejms:connection).receiverSettings - a reference to a JmsReceiverSettings bean, which provides access to advanced settings that are usually shared across all configured receivers. Default value is provided by the parent connection’s defaultReceiverSettings property (which is usually a reference to the JmsReceiverSettings bean instance defined in the jms-global-spring.xml file).This bean defines a single-threaded context for sending events to a JMS destination, and results in the creation of a correlator output channel called jms:senderId. It has no required properties.
Example:
<jms:sender id="mySender">
<property name="senderReliability" value="BEST_EFFORT"/>
<property name="messageDeliveryMode" value="PERSISTENT"/>
<property name="senderSettings" ref="globalSenderSettings"/>
</jms:sender>
Supported properties:
senderReliability - the Apama reliability mode to use when events are sent to JMS. Valid values are BEST_EFFORT, AT_LEAST_ONCE, EXACTLY_ONCE. Default value is provided by the parent jms:connection’s defaultSenderReliability setting.messageDeliveryMode - this property applies to a sender that is using the BEST_EFFORT reliability mode to deliver messages to a JMS broker. The default is the JMS NON_PERSISTENT delivery mode. You can change the value of this property to PERSISTENT mode. While PERSISTENT mode is slower, it causes the JMS broker to write messages to disk to protect against crashes of the JMS broker node. The only possible values for the messageDeliveryMode property are PERSISTENT and NON_PERSISTENT. This property is ignored for other reliable senders.senderSettings - a reference to a JmsSenderSettings bean, which provides access to advanced settings that are usually shared across all configured senders. Default value is provided by the parent connection’s defaultSenderSettings property (which is usually a reference to the JmsSenderSettings bean instance defined in the jms-global-spring.xml file).This bean defines a database used by Apama to implement reliable receiving. It has no required properties. Typically all connections in a correlator will share the same receive database; if the correlator is not started with the -P (persistence enabled) flag, this bean will be ignored.
Example:
<bean id="myReliableReceiveDatabase"
class="com.apama.correlator.jms.config.DefaultReliableReceiveDatabase">
<property name="storePath" value="jms/my-receive.db"/>
<!-- either absolute path, or path relative to correlator store location -->
</bean>
Supported property:
storePath - the path where the message store database should be created. Default value is jms-receive-persistence.db. Use an absolute path, or a path relative to the store location specified for use by the correlator state persistence store on the correlator command line.To protect the security of personal data, see Protecting personal data in Apama applications.
This bean defines advanced settings for message senders. It has no required properties. Typically all senders in all connections will share the same JmsSenderSettings bean, but it is also possible to use different settings for individual senders.
Example:
<bean id="globalSenderSettings"
class="com.apama.correlator.jms.config.JmsSenderSettings">
<property name="logJmsMessages" value="false"/>
<property name="logJmsMessageBodies" value="false"/>
<property name="logProductMessages" value="false"/>
</bean>
Supported properties:
logJmsMessages - if true, log information about all JMS messages that are sent (but not the entire body) at INFO level. Default value is false.logJmsMessageBodies - if true, log information about all JMS messages that are sent, including the entire message body at INFO level. Default value is false.logProductMessages - if true, log information about all Apama events that are sent at INFO level. Default value is false.logDetailedStatus - Enables logging of a dedicated INFO status line for each sender and a summary line for each parent connection. The default value is false (detailed logging is disabled), which results in a single summary line covering all senders and connections.logPerformanceBreakdown - Enables periodic logging of a detailed breakdown of how much time is being taken by the different stages of mapping, sending, and disk operations for each sender. By default, the messages are logged every minute at the INFO level. The interval can be changed if desired. The default is false, and Apama recommends disabling this setting in production environments to prevent the gathering of the performance information from reducing performance.logPerformanceBreakdownIntervalSecs - Specifies the interval in seconds over which performance throughput and timings information will be gathered and logged. Default is 60.sessionRetryIntervalMillis - Specifies how long to wait between attempts to create a valid JMS session and producer for this sender either after a serious error while using the previous session or after a previous failed attempt to create the session. However, if the underlying JMS connection has failed the connectionRetryIntervalMillis is used instead. Default value is 1000 ms.This bean defines advanced settings for message receivers. it has no required properties. Typically all receivers in all connections will share the same JmsReceiverSettings bean, but it is also possible to use different settings for individual receivers.
Example:
<bean id="globalReceiverSettings"
class="com.apama.correlator.jms.config.JmsReceiverSettings">
<property name="dupDetectionPerSourceExpiryWindowSize" value="2000"/>
<property name="dupDetectionExpiryTimeSecs" value="120"/>
<property name="logJmsMessages" value="false"/>
<property name="logJmsMessageBodies" value="false"/>
<property name="logProductMessages" value="false"/>
</bean>
Supported properties:
logJmsMessages - if true, log information about all JMS messages that are received (but not the entire body) at INFO level. Default value is false.
logJmsMessageBodies - if true, log information about all JMS messages that are received, including the entire message body at INFO level. Default value is false.
logProductMessages - if true, log information about all Apama events that are received at INFO level. Default value is false.
logDetailedStatus - Enables logging of a dedicated INFO status line for each receiver and a summary line for each parent connection. The default value is false (detailed logging is disabled), which results in a single summary line covering all receivers and connections.
logPerformanceBreakdown - Enables periodic logging of a detailed breakdown of how much time is being taken by the different stages of mapping, receiving, and disk operations for each receiver. By default, the messages are logged every minute at the INFO level. The interval can be changed if desired. The default is false, and Apama recommends disabling this setting in production environments to prevent the gathering of the performance information from reducing performance.
logPerformanceBreakdownIntervalSecs - Specifies the interval in seconds over which performance throughput and timings information will be gathered and logged. Default is 60.
dupDetectionPerSourceExpiryWindowSize - used for EXACTLY_ONCE receiving, and specifies the number of messages that will be kept in each duplicate detection domain per messageSourceId (if messageSourceId is set on each message by the upstream system - messages without a messageSourceId will all be grouped together into one window for the entire dupDetectionDomainId). Default value is “2000”. It can be set to 0 to disable the fixed-size per-sender expiry window.
dupDetectionExpiryTimeSecs - used for EXACTLY_ONCE receiving, and specifies the time for which uniqueMessageIds will be remembered before they expire. Default value is “120”. It can be set to 0 to disable the time-based expiry window.
maxExtraMappingThreads - Specifies the number of additional (non-receiver) threads to use for mapping received JMS messages to Apama events. The default value is 0. Using a value of 1 means all mapping is performed on a separate thread to the thread receiving messages from the bus; a value greater than 1 provides additional mapping parallelism. This setting cannot be used if maxBatchSize has been set to 1. Using multiple separate threads for mapping may improve performance in situations where mapping of an individual message is a heavyweight operation (for example, for complex XML messages) and where adding separate receivers is not desired (because they involve the overhead of additional JMS sessions and reduced ordering guarantees). Note that strictly speaking JMS providers do not have to support multi-threaded construction of JMS messages (since all JMS objects associated with a receiver’s Session are meant to be dedicated to a single thread), so although in practice it is likely to be safe, it is important to verify that this setting does not trigger any unexpected errors in the JMS provider being used.
The order in which mapped events are added to the correlator input queue (of each public context) is not changed by the use of extra mapping threads, as messages from all mapping threads on a given receiver are put back into the original receive order at the end of processing each receive batch.
sessionRetryIntervalMillis - Specifies how long to wait between attempts to create a valid JMS session and consumer for this receiver either after a serious error while using the previous session, or after a previous failed attempt to create the session. However, if the underlying JMS connection has failed the connectionRetryIntervalMillis is used instead). Default value is 1000 ms.
receiverFlowControl - Specifies whether application-controlled flow is enabled for each receiver. When set to true, application-controlled flow control is enabled for each receiver, by listening for the com.apama.correlator.jms.JMSReceiverFlowControlMarker event and responding by calling the updateFlowControlWindow() action as appropriate. Default value is false.
The following properties are advanced tuning parameters, for use only when really necessary to improve performance or work around a JMS provider bug. Since these are advanced properties, it is possible that the default values may change in any future release or that new tuning parameters may be added that could alter the semantics of the existing ones, so be sure to carefully check the Release Notes when upgrading, if you use any of these properties.
maxBatchSize - The maximum (and target) number of events to be batched together for sending inside a JMS local (non-XA) transaction (which improves performance on many JMS providers). The maxBatchSize indicates the target number of events that will normally be sent in a single batch unless the maxBatchIntervalMillis timeout expires first. The maxBatchSize must be greater than 0 and the special value of 1 is used to indicate that a non-transacted JMS session should be used instead. Note that the same batching algorithm and parameters are used for both reliable and non-reliable senders. The default value in this release is 500.maxBatchIntervalMillis - The maximum time a sender will wait for more events on its channel (and for reliable senders, also included in a correlator persist cycle) before timing out and sending the events ready to be sent in the batch, even if the batch size is less than maxBatchSize. The default value in this release is 500 ms.receiveTimeoutMillis - The timeout that will be passed to the JMS provider’s MessageConsumer.receive(timeout) method call to indicate the maximum time it should block for when receiving the next message before returning control to the correlator. The default value in this release is 300 ms. Some providers may require this timeout to be increased to ensure that messages can be successfully received in high-latency network conditions, although well-behaved providers should always work correctly with the default value. Reducing this timeout may improve receive latency (due to reduced time waiting for the batch to complete) on some providers; although note that many JMS providers do not strictly obey the timeout specified here so the real time spent blocking while no messages are available may be significantly higher.
maxBatchSize - The maximum (and target) number of JMS messages to be received before the batch is committed to the receive-side database (if receiver is using AT_LEAST_ONCE or EXACTLY_ONCE reliability mode) and then added to the input queues of public contexts and acknowledged to the JMS broker (whether reliable or not). The maxBatchSize indicates the target number of messages that will normally be received in a single batch unless the maxBatchIntervalMillis timeout expires first. The maxBatchSize must be greater than 0 and for BEST_EFFORT (non-reliable) receivers the special value of 1 is used to indicate that an AUTO_ACKNOWLEDGE session will be used instead of the default CLIENT_ACKNOWLEDGE session (though for reliable receivers CLIENT_ACKNOWLEDGE is always used even if maxBatchSize is 1). The default value in this release is 1000.
The batch size becomes particularly important when using the APP_CONTROLLED reliability mode. In this case, you might need to tweak the batch size to improve throughput based on how long the application takes between suspending and acknowledging each batch of messages.
maxBatchIntervalMillis - the maximum time a receiver will attempt to wait for more messages to be received (and mapped) before timing out and processing the messages already received as a single batch, even if the size of that batch is less than maxBatchSize. The default value in this release is 500 ms. Note that in practice, when no messages are available, many JMS providers seem to block for longer than the specified receiveTimeoutMillis before returning, which may lead to the true maximum batch interval being significantly longer than the value specified here.
The following properties are advanced tuning parameters, for use only when really necessary to improve performance or work around a JMS provider bug. Since these are advanced properties, it is possible that the default values may change in any future release or that new tuning parameters may be added that could alter the semantics of the existing ones, so be sure to carefully check the Release Notes when upgrading, if you use any of these properties.
maxBatchSize - The maximum (and target) number of events to be batched together for sending inside a JMS local (non-XA) transaction (which improves performance on many JMS providers). The maxBatchSize indicates the target number of events that will normally be sent in a single batch unless the maxBatchIntervalMillis timeout expires first. The maxBatchSize must be greater than 0 and the special value of 1 is used to indicate that a non-transacted JMS session should be used instead. Note that the same batching algorithm and parameters are used for both reliable and non-reliable senders. The default value in this release is 500.maxBatchIntervalMillis - The maximum time a sender will wait for more events on its channel (and for reliable senders, also included in a correlator persist cycle) before timing out and sending the events ready to be sent in the batch, even if the batch size is less than maxBatchSize. The default value in this release is 500 ms.receiveTimeoutMillis - The timeout that will be passed to the JMS provider’s MessageConsumer.receive(timeout) method call to indicate the maximum time it should block for when receiving the next message before returning control to the correlator. The default value in this release is 300 ms. Some providers may require this timeout to be increased to ensure that messages can be successfully received in high-latency network conditions, although well-behaved providers should always work correctly with the default value. Reducing this timeout may improve receive latency (due to reduced time waiting for the batch to complete) on some providers; although note that many JMS providers do not strictly obey the timeout specified here so the real time spent blocking while no messages are available may be significantly higher.
maxBatchSize - The maximum (and target) number of JMS messages to be received before the batch is committed to the receive-side database (if receiver is using AT_LEAST_ONCE or EXACTLY_ONCE reliability mode) and then added to the input queues of public contexts and acknowledged to the JMS broker (whether reliable or not). The maxBatchSize indicates the target number of messages that will normally be received in a single batch unless the maxBatchIntervalMillis timeout expires first. The maxBatchSize must be greater than 0 and for BEST_EFFORT (non-reliable) receivers the special value of 1 is used to indicate that an AUTO_ACKNOWLEDGE session will be used instead of the default CLIENT_ACKNOWLEDGE session (though for reliable receivers CLIENT_ACKNOWLEDGE is always used even if maxBatchSize is 1). The default value in this release is 1000.
The batch size becomes particularly important when using the APP_CONTROLLED reliability mode. In this case, you might need to tweak the batch size to improve throughput based on how long the application takes between suspending and acknowledging each batch of messages.
maxBatchIntervalMillis - the maximum time a receiver will attempt to wait for more messages to be received (and mapped) before timing out and processing the messages already received as a single batch, even if the size of that batch is less than maxBatchSize. The default value in this release is 500 ms. Note that in practice, when no messages are available, many JMS providers seem to block for longer than the specified receiveTimeoutMillis before returning, which may lead to the true maximum batch interval being significantly longer than the value specified here.