JMS Kafka Divert Limitations
This content is for the 3.3.6 version. Switch to the latest version for up-to-date documentation.
JMS Producer to Kafka Topic Divert Processing on Crash Flow
Following flow highlights limitation that asynchronous processing of divert in Kafka Streams based message journal can have upon crash of JMS Bridge node. Kafka Streams processing state is saved periodically (known as Commit) and upon crash, the state is restored from the last commit point. Due to this, messages can be re-produced to Kafka Topics after JMS Bridge node crash - causing duplication on Kafka Topics only.
Sequence diagram below illustrates a flow where:
- Message 1 is sent by JMS Producer
- Message 1 is ingested into Journal
- Message 1 is Acked back to JMS Producer
- Message 1 is diverted to Kafka
- KStreams state committed
- Messages 2,3 are ingested into Journal
- Messages 2,3 are Acked back to JMS Producer
- Messages 2,3 are diverted to Kafka
- Message 4 is sent by JMS Producer
- Message 4 is ingested into Journal
- JMS Bridge crashes
- Standby JMS Bridge takes over
- KStreams state is restored from last commit point
- Messages 2,3 are re-processed and diverted to Kafka again (causing duplicates on Kafka Topic)
- Message 4 is diverted to Kafka
- JMS Producer sends Message 4* again (retry as Ack was not returned from JMS Bridge due to crash even though message was persisted to Journal)
- Message 4* is ingested into Journal again (retry - duplicate on JMS Queue / Topic)
- Message 4* is Acked back to JMS Producer (retry)
- Message 4* is diverted to Kafka (retry - duplicate on Kafka Topic)
The handling of Message 4 is consistent with Vanilla Artemis and guarantees in Sync send mode, but duplication caused by reprocessing divert for messages 2 and 3 are side effects of Kafka Streams processing and asynchronous state commit.