One thing that could cause pauses like that is the JVM's garbage collector. What GC strategy are you using, and can you see if the times at which the higher latency occurs correlate with the times at which full GCs are occurring?
Tim On Feb 9, 2018 1:53 AM, "alprausch77" <joachim.gl...@dematic.com> wrote: > 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 > /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./ > > > 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. > > btw: we are running AMQ 5.14.5 (unfortunatelly on Windows) > > > > -- > Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User- > f2341805.html >
