In addition to specifying static senders and receivers in the adapter's configuration file, Apama has a new event API that allows senders and receivers to be added and removed dynamically from EPL code. This provides the ability to receive from a topic or queue, the name of which is known only at runtime. For advanced users, it provides a way to allow an application to implement dynamic scaling of the number of sender and receiver threads in order to improve performance, based on any policy specific to the application's use case.

JMS durable topic subscriptions are supported for dynamic and static receivers. This enables an Apama application to persistently register interest in a topics messages with the JMS broker such that even if a correlator is down, messages sent to the queue will be held and be ready for delivery when the correlator recovers.

Status notification events (such as OK, CONNECTING, ERROR, FATAL_ERROR, and REMOVED) are now sent for each JMS connection, receiver, and sender.

The maxExtraMappingThreads property has been added to ReceiverSettings. This supports scaling receive-side mapping work (especially expensive XML parsing) across multiple cores without needing to add extra JMS receivers, which often adds a considerable extra burden, and breaks message ordering). By default it is set to 0 (that is, do mapping on the same thread as receiving). While this property should be used with extreme care, it provides a very useful tool for cases where performance needs to be improved.

Receive message mapping conditional expression improvements:

The jms.body.type conditional expression has been added. This provides for discriminating between TextMessage, MapMessage, etc

Added support for empty JUEL keyword, and checking the values of properties and headers that might not have been set.

Periodic "JMS Status:" INFO log messages, similar to the existing correlator status log messages, are now logged for correlators with Correlator-integrated JMS enabled. The JMS Status messages include diagnostic info such as number of outstanding sent events, totals send/received, used JVM memory, etc.

A new receiver/sender settings property called logPerformanceBreakdown can be enabled to provide detailed information highlighting where performance bottlenecks may be occurring.

The JMSSender.getOutstandingEvents action has been added to the event API. This can be useful for throttling the rate at which messages are emitted from an EPL application in order to avoid the JMS sender getting too far behind (and using up excessive memory as a result).

A new receiverFlowControl property has been added to provide EPL applications with control over the rate at which events are taken from the JMS queue or topic by each JMS receiver.

Many limitations on convention-based mapping have been removed. For example

Element names containing hyphens and dots can be represented using $002d and $002e, respectively.

Mapping both text and attribute/child node data from the same XML node is supported.

Mapping attribute values to EPL integer, float, and boolean fields is supported.

Apama provides new sample applications that illustrate the use of Correlator-integrated JMS messaging. The apama_dir\samples\correlator_jms directory contains the following sample applications:

simple-send-receive - This application demonstrates simple sending and receiving. It sends a sample event to a JMS queue or topic as a JMS TextMessage using the automatically configured default sender and receives the message using a statically-configured receiver.

dynamic-event-api - This application demonstrates how to use the event API to dynamically add and remove JMS senders and receivers. In addition, it shows how to monitor senders and receivers for errors and availability.

flow-control - This application demonstrates how to use the event API to avoid sending events faster than JMS can cope with and a separate demonstration of how to avoid receiving messages from JMS faster than the EPL application can cope with.