Hello.
I have a question about the AMQ-3166 issue and the introduced
'rollbackOnlyOnAsyncException' flag.
In the comments of the AMQ-3166 task Gary Tully says
<li>async exceptions on transactional ops - message send and message ack
will result in the transaction being marked rollback-only. Commit will fail
with an exception.</li>
But if I send the message in async mode than it´s likely that the client
side transaction is already committed before(!) an exception occurs on the
AMQ side. In that case the TransportConnection class will no longer find a
transaction for the message (as it´s already committed) and of course it
can´t be rolled-back anymore.
Or do I misunderstand the behaviour?
My current problem is that we switched from async to sync sends because
we´ve seen some messages getting lost without "seeing" it on the client
side. For our use-case it´s not acceptable to have a message loss. So we
switched to the sync send.
But this comes with a high performance impact.
We are seeing a lot of messages to be send in 0-3ms but we see occassional
spikes in the send times (in the ActiveMQMessageProducer) of 30-500ms.
The 'producerFlowControl' is already disabled in the configuration; the
storage is mKahaDB.
And we already tested a lot of configuration combinations with no real
(positive) effect on the performance.
Is there a way to avoid such spikes in the sync send?
(Tests has shown that the spikes are most likely caused due to I/O issues.
Because when using a RAM disk as location for the kahaDB I don´t see any
such spikes.)
Or in async mode: is there a way to have a synchronization on transaction
commit which verifies that the message is processed?
This way the message processing could be triggered in async mode and the
client could do further work and only synchronizes on the transaction
commit.
Thanks.
Joachim
btw: we are running AMQ 5.14.5 (unfortunatelly on Windows)
--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html
