Deploying and Managing Apama Applications > Correlator-Integrated JMS Messaging > Designing and implementing applications for JMS > Using correlator persistence with Correlator-integrated JMS > How reliable JMS sending integrates with correlator persistence
How reliable JMS sending integrates with correlator persistence
This topic describes the details of how JMS sending integrates with correlator persistence and is intended for advanced users.
When sending JMS messages in a persistent correlator, all events emitted to a JMS sender are queued inside the correlator until the next persist cycle begins. The events cannot be passed to JMS until the EPL application state changes that caused them to be sent have been persisted, otherwise the downstream receiver might see an inconsistent set of events in the case of a failure and recovery. Note that to avoid potentially inconsistent output in the event of a failure, this is true not only for reliable AT_LEAST_ONCE and EXACTLY_ONCE messages but also for BEST_EFFORT messages in a persistent correlator. The only differences between BEST_EFFORT and the reliable sending modes (other than whether the messages use the JMS PERSISTENT delivery mode flag), is that for the reliable modes the messages are guaranteed to remain on disk until they have been successfully sent to the JMS broker, whereas for BEST_EFFORT this is not the case.
Unique identifiers are generated and assigned to each message when they are emitted, and persisted with the events to allow downstream receivers to perform EXACTLY_ONCE duplicate detection if desired (note, this assumes the uniqueMessageId is mapped into the JMS message in some fashion).
Once the next persist cycle has completed and both the events and the application state that caused them has been committed to disk, the events can be sent to JMS. After messages have been successfully sent to the JMS broker they are lazily removed from the correlator's in-memory and on-disk data structures. The latency of sent messages is therefore dependent on the time taken for the correlator to perform a persist cycle (including the persist interval, the time taken to snapshot the correlator's state and commit it to disk, and any retries if the state cannot be snapshotted immediately), plus any time spent waiting to fill the batch of events to be sent (although this is usually relatively small). Note that if a message send fails and it is not due to the JMS connection being lost then after a small number of retries it will be dropped with an ERROR message in the log. If a send fails because the connection is down, the correlator simply waits for it to come up again in all cases.
Copyright © 2013 Software AG, Darmstadt, Germany and/or Software AG USA Inc., Reston, VA, USA, and/or Terracotta Inc., San Francisco, CA, USA, and/or Software AG (Canada) Inc., Cambridge, Ontario, Canada, and/or, Software AG (UK) Ltd., Derby, United Kingdom, and/or Software A.G. (Israel) Ltd., Or-Yehuda, Israel and/or their licensors.