Thanks for your replies!
Yes, we are using ActiveMQ Artemis and only with the CORE protocol.
So, to my understanding async send acks do:
1. ensure message ordering as long as the same producer sends the messages
2. offer maximum performance
3. do not impose memory requirements on server-side (as large transactions do)
The same applies to transactional sends besides the memory aspect, although
they are not designed for performance.
I feel comfortable with that because it offers two options for us the increase
performance and we can choose which serves best for each situation.
Thanks again and kind regards. Keep up the good work!
Sebastian
-----Ursprüngliche Nachricht-----
Von: Justin Bertram <jbert...@apache.org>
Gesendet: Mittwoch, 5. Juni 2024 22:44
An: users@activemq.apache.org
Betreff: Re: Asynchronous Send Acknowledgements
I believe the answer to your question is in the relevant JavaDoc [1] which
states this regarding messages sent with a CompletionListener:
Message order: If the same MessageProducer is used to send multiple
messages then JMS message ordering requirements must be satisfied. This applies
even if a combination of synchronous and asynchronous sends has been performed.
The application is not required to wait for an asynchronous send to complete
before sending the next message
Regarding which is "better" between async send acks and batched transactional
sends, I think that ultimately boils down to your use-case.
If you want the absolute best performance I think async send acks is better.
The performance and reliability is excellent. If you pair it with duplicate
detection [2] the reliability is equivalent to a transaction.
This mechanism is used by ActiveMQ Artemis core bridges [3] to move messages
between brokers and also internally between nodes in a cluster.
The only down-side I can think of is that despite the fact that this kind of
async paradigm is common in modern applications some developers may have
trouble wrapping their minds around it.
Batched transactional sends will also provide reliability and good performance
relative to non-batched synchronous sends. They are also conceptually more
straight-forward so some developers will be more comfortable with them.
However, there is some tuning involved because you want the size of the
transaction to be large enough to yield an overall performance benefit, but you
don't want it to be too large that a rollback requires duplicating a lot of
work and wasting resources. Also, the broker has to maintain metadata about the
transaction so the larger the transaction the more memory the broker will have
to use. This is why large transactions are considered an anti-pattern. Lastly,
it's worth mentioning that while the batching functionality provided by a
transaction can yield a performance increase in some cases, transactions were
designed to provide ACID guarantees, not performance.
Also, can you confirm you're using ActiveMQ Artemis?
Justin
[1]
https://docs.oracle.com/javaee/7/api/javax/jms/MessageProducer.html#send-javax.jms.Message-javax.jms.CompletionListener-
[2]
https://activemq.apache.org/components/artemis/documentation/latest/duplicate-detection.html#duplicate-message-detection
[3]
https://activemq.apache.org/components/artemis/documentation/latest/core-bridges.html#core-bridges
On Wed, Jun 5, 2024 at 2:33 AM <s.go...@inform-technology.de> wrote:
> I have a question concerning Asynchronous Send Acknowledgements.
>
> As I have understood this feature, it basically does not wait for the
> message to be persisted but dispatches this to an asynchronous handler.
>
> As I have a use-case where the ordering of the sent messages is
> important, I would like to know if this mode does guarantee the order of
> messages.
>
>
>
> In the same context another question is, what is the better choice:
> Asynchronous Send Acknowledgements or Transactional Sends when sending
> several messages at once?
>
>
>
> Kind regards
>
>
>
> Sebastian
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@activemq.apache.org
For additional commands, e-mail: users-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
