This topic describes the details of how JMS sending integrates with correlator persistence. This information is intended for advanced users.

When sending JMS messages in a persistent correlator using any reliability mode other than BEST_EFFORT, all events sent 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. In addition, messages sent using any of the reliable modes are sent with the JMS PERSISTENT delivery mode flag by default, and are guaranteed to remain in the correlator's persistence store until they have been successfully sent to the JMS broker (or until the send failed for a reason other than connection loss).

Unique identifiers are generated and assigned to each message when they are sent, 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 have 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 required to take a snapshot the correlator's state and commit it to disk, and any retries if the correlator cannot take a snapshot for the state 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.

When sending messages in a persistent correlator using BEST_EFFORT, the behavior is different. In this case, messages are passed to JMS immediately without waiting for a correlator persistence cycle. This results in lower latency, but also means it is possible for a client receiving JMS messages sent by the correlator to see inconsistent output in the event of a correlator failure. For example, the correlator might send one set of messages with unique identifiers (for example, from integer.incrementCounter()) but on restart send similar messages but in a different ordering, while responses from the first set of messages may then be received, resulting in mismatches between the requests and the responses being processed.