I'm not sure on the broker side of things, but from the client side... The original JMS MessageProducer APIs essentially expected all sends to be synchronous, and so lacked any specific way to signal a useful async send error or success to the application (beyond the connectionException Listener, and tearing down the entire Connection, still without any useful way to note to the application which sends actually completed vs not) . Many JMS clients send at least non-persistent messages (already deemed to have lower delivery guarantee) asynchronously by default regardless of this, due to users wanting them to perform faster and noting as you do below that the more reliable synchronous sending is slower than the unreliable async sending. As a result though, when the send call returns on an async send that in no way means the message has arrived or necessarily will arrive at the broker. It may not. Especially if the connection drops, or the server fails to process the message in some way.
If you are seeing asynchronous sends then you are presumably either sending non-persistent messages, or using the URI options to force async sends for persistent ones. You essentially answered the main suggestion here yourself in that case. If you were to use synchronous sends, then you will be signalled when any specific send has failed to complete successfully, as you seem to desire, but it will obviously usually come with a performance reduction from actually awaiting the response before returning from the send call. JMS 2 also added a specific asynchronous send API with use of CompletionListener callbacks to allow doing reliable asynchronous sending, also potentially reducing the performance hit vs synchronous since you can send additional messages before later handling or verifying the result of earlier ones, effectively batching. I don't know that the Spring bits can leverage those APIs, though perhaps you could do so directly. On Mon, 11 Aug 2025 at 14:18, SZOMBATHY Mátyás < [email protected]> wrote: > Hi, > > Just some clarification for the below story. > The events-dispatcher is a service we use for publishings messages, its > the only container containing publishers. > We use spring-boot-starter-amqp for communicating with both RMQ and AMQ. > > Our problem is simple: AMQ just drops messages and our producer doesnt > care about it. > Of course as you said we should set syncronous mode to deal with it, but > it had some negative effect on performance (I’m still trying to figure out > how could RMQ be fast enough on quorum queues no less) > > Either way, even if its async, it shouldn’t drop messages „randomly”. > The producer doesn’t log any errors and we are running on INFO level. > AMQ itself only logs the below line, even tho we tried to add the DEBUG > options. > > Any idea is welcome at this point, as I only left with two choices: > - Switch to sync producers for AMQ > - Switch to RMQ > > > > Thank you! > Mátyás > > > > <http://www.scientificgames.com/> > > * Mátyás SZOMBATHY* > Lead DevOps Engineer (UPAM) > *Scientific Games* > M: +36 30 950 6846 > > > HAVE FUN. DO GOOD. *PLAY HEALTHY.* > May be privileged. May be confidential. Please delete if not the > addressee. > > > <http://www.scientificgames.com/> * Mátyás SZOMBATHY* > Lead DevOps Engineer > *Scientific Games* > M: +36 30 950 6846 > HAVE FUN. DO GOOD. *PLAY HEALTHY.* > > Scientific Games Kft., 1011 Budapest, Fő utca 14-18, Hungary > May be privileged. May be confidential. Please delete if not the > addressee. > > *From:* KASSA Máté <[email protected]> > *Sent:* Monday, August 11, 2025 2:47 PM > *To:* [email protected] > *Cc:* UPAM_DEVOPS <[email protected]> > *Subject:* Issue with Lost Events in ActiveMQ Classic 6.1.X > > > > Dear Support, > > > > I'm reaching out regarding an issue with an ActiveMQ instance where *certain > events are reported as published but are never consumed* - indicating > they were never actually received. Each time this occurs, *we observe the > only following warning in the AMQ log:* > > - *2024-04-01 10:25:18,236 | WARN | Async error occurred | > org.apache.activemq.broker.TransportConnection.Service | ActiveMQ > Transport: tcp:///11.11.111.11:58808@61515* > > > > Notably, the event dispatcher does not raise any errors when this happens, > which suggests the issue may be internal to ActiveMQ. > > In a previous response, I was informed that: > > - This error is caused by any process that fails on the broker side and is > handled by the serviceException method. The resulting behavior is that the > exception is sent to the client. > > - You can try disabling sendAsync and rely on client acknowledgments > instead, if you're currently using sendAsync on the producer. > > > > *Could you please help clarify what might be causing this issue and > suggest any further steps (guide) to resolve it?* > > > > Thank you in advance. > > > > Best regards, > > Máté >
