Re: Question about rollbackOnlyOnAsyncException (AMQ-3166)

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

Re: Question about rollbackOnlyOnAsyncException (AMQ-3166)

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

Re: Question about rollbackOnlyOnAsyncException (AMQ-3166)

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

Re: Question about rollbackOnlyOnAsyncException (AMQ-3166)

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

Re: Question about rollbackOnlyOnAsyncException (AMQ-3166)

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 >

Re: Question about rollbackOnlyOnAsyncException (AMQ-3166)

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,

Re: Question about rollbackOnlyOnAsyncException (AMQ-3166)

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:

Re: Question about rollbackOnlyOnAsyncException (AMQ-3166)

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"