I have two separate processes running the same Camel routes the consume from an ActiveMQ topic (i.e.: a topic with multiple subscribers) and occasionally experienced missed messages on one of the consumers. I want both consumers to receive the same messages, hence why I'm using a topic.
What I think is happening is that one of the consumers errors while committing its database transaction because I see a log like this:
WARN arjuna | || ARJUNA012125: TwoPhaseCoordinator.beforeCompletion - failed for SynchronizationImple< 0:ffff0a666262:e5aa:557ac1a0:14976, org.hibernate.engine.transaction.synchronization.internal.RegisteredSynchronization@6dc34434 >
WARN DefaultJmsMessageListenerContainer | || Setup of JMS message listener invoker failed for destination 'xxx' - trying to recover. Cause: JTA transaction unexpectedly rolled back (maybe due to a timeout); nested exception is javax.transaction.RollbackException: ARJUNA016053: Could not commit transaction.
INFO DefaultJmsMessageListenerContainer | || Successfully refreshed JMS Connection
It appears that while this is going on the consumer in the other process receives another message from the topic and processes it, however this second message is not received by the first consumer (the one that logged the warnings).
I'm far from familiar with the internals of the Spring message listener, but does the connection refresh momentarily make the topic subscription disappear? Would that explain why broadcast messages are occasionally missed after a listener error?
Does anybody have any suggestions what I might be doing wrong, or are my expectations out of line with how topics are supposed to behave?
Maybe this info help you:
For a set of messages arriving in order [A, B, C, D] and for two consumers C1 and C2, the normal distribution of messages will be as follows:
C1: [A, C] C2: [B, D] Since the broker does not control the work of read processes and the processing order is parallel, it is non-deterministic. If C1 is slower than C2, then the initial set of messages can be processed as [B, D, A, C].
This behavior may surprise newbies who expect messages to be processed in order and build their messaging application on this basis. The requirement that messages sent by the same sender be processed in relative order, also known as causal ordering, is fairly common.
https://habr.com/ru/post/471268/