I'd echo Gary's suggestion that you capture thread dumps or perform
sampling during the slow events. That would make it clear where the time is
being spent.
Tim
On Wed, Feb 14, 2018 at 11:16 PM, alprausch77
wrote:
> Yes, we use XA transactions.
>
> I don´t think that the NIO mixes this up some
Yes, we use XA transactions.
I don´t think that the NIO mixes this up somehow. We can run our system with
a standalone ActiveMQ using tcp or nio but also in an embedded mode inside
Wildfly using the VM protocol.
I just run our tests again with the enableAckCompaction set to false for the
kahaDB -
XA transactions?
normally the transaction is on the session and connection... so any async
call will complete before the commit.. unless maybe nio is mixing this up
some.
do you have some code that will show the rollbackOnlyOnAsyncException case
where the tx is null.
There is a test case that can
Hello Gary.
Thanks for your reply.
I already tried the rollbackOnlyOnAsyncException. But this one only works if
the transaction still exists when the error in the async send happens.
But if the TX is already finished, than there is no such action because the
code which looks up the transaction retu
in addition, try the latest Artemis release, there has been a bunch of work
on latency w.r.t gc on exactly that flat send latency (reliable enqueue)
use case.
On Wed, 14 Feb 2018 at 14:29 Gary Tully wrote:
> transaction commit is a sync operation... if an async send in a
> transaction fails, the
transaction commit is a sync operation... if an async send in a transaction
fails, then the commit will rollback via: rollbackOnlyOnAsyncException
w.r.t spikes in send, have you enabled the preallocation strategy on
kahadb, it may be worth toggling to see the effect in your env. Also,
ackCompactio
Hello Tim.
Thank you for your suggestion but I already checked the GC (forgot to
mention it).
The times of the slow JMS sends doesn´t correlate with the garbage collector
events.
Btw: we use CMS as collector.
Any other ideas?
Thanks.
Joachim
--
Sent from: http://activemq.2283324.n4.nabble.com/
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" wrote:
> Hello.
> I hav