Apama 10.3 | Apama Documentation | Connecting Apama Applications to External Components | Correlator-Integrated Support for the Java Message Service (JMS) | Using the Java Message Service (JMS) | Designing and implementing applications for correlator-integrated messaging for JMS | Using correlator persistence with correlator-integrated messaging for JMS | How reliable JMS receiving integrates with correlator persistence
How reliable JMS receiving integrates with correlator persistence
This topic, for advanced users, describes how JMS receiving integrates with correlator persistence.
When receiving in AT_LEAST_ONCE or EXACTLY_ONCE mode, messages are taken from the JMS queue or topic in batches (using JMS CLIENT_ACKNOWLEDGE mode). The resulting Apama events are persisted in the reliable receive datastore (which is separate from the correlator's recovery datastore) and then acknowledged back to JMS before the next batch of messages is received. After a batch of events finishes being asynchronously committed to the datastore, it is added to the input queue of each context. When the correlator next completes a persist cycle, all events that had at least been added to the input queue by the beginning of the persist cycle have been (or will be) reliably passed to the application. This means that in AT_LEAST_ONCE mode they can be removed from the receive datastore immediately.
If EXACTLY_ONCE is being used and the event was mapped with a non-empty uniqueMessageId from the JMS message, the uniqueMessageId and other metadata are stored both in memory and in the on-disk reliable datastore, and are kept there until the associated uniqueMessageId is expired from the duplicate detector. Note however, that as an optimization, because the persisted event strings are no longer needed once the event has been included in the correlator state database, any particularly long event strings may become null in the database. The latency of received messages is therefore dependent on the time spent waiting for other messages to be received to fill the batch, and the time taken to commit the batch to the receive datastore.
When a persistent correlator is restarted and recovers its state from the recovery datastore, no new JMS messages will be received from the broker until recovery is complete. Specifically, until the correlator calls the onConcludeRecovery() action on all EPL monitors that have defined this action. It is possible that EPL monitors will see a small number of JMS messages that were received and added to the input queue before the correlator was restarted. To be safe, any required listeners in non-persistent monitors should be set up in onBeginRecovery().
Since a batch of messages is acknowledged to the JMS broker as soon as they have been written to the Apama reliable receive datastore, there is no relationship between JMS message acknowledgment to the broker and when the correlator begins or completes a correlator state datastore persistence cycle. The maximum number of messages that may be received from the JMS broker but not yet acknowledged is limited by the configured maxBatchSize (typically this is 1000 messages).

Copyright © 2013-2018 | Software AG, Darmstadt, Germany and/or Software AG USA, Inc., Reston, VA, USA, and/or its subsidiaries and/or its affiliates and/or their licensors.