Re: mKahaDB - no clean-up because of ACKs

Hello Tim. Thanks for the hint about the XA transactions. There were indeed 2 XA transactions hanging in the kahaDB files. After I committed them via JConsole the store was cleaned-up. Joachim -- Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html

mKahaDB - no clean-up because of ACKs

Hello. Recently we had a problem on a ActiveMQ 5.10 version (with manually applied patch for AMQ-5542). The mKahaDB data store increased to ~30 GB and couldn´t clean up the data files anymore. The log showed always something like this: /not removing data file: 317633 as contained ack(s) refer to r

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)

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

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: http://activemq.2283324.n4.nabble.com/

Question about rollbackOnlyOnAsyncException (AMQ-3166)

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 w

Question about rollbackOnlyOnAsyncException (AMQ-3166)

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

Re: UseDedicatedTaskRunner configuration

Thanks for the answer. I´ve created the JIRA issue https://issues.apache.org/jira/browse/AMQ-6883 -- Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html

UseDedicatedTaskRunner configuration

Hello. The documentation (http://activemq.apache.org/how-do-i-configure-10s-of-1000s-of-queues-in-a-single-broker-.html) states that the DedicatedTaskRunner is disabled by default from 5.6 onwards. This is true if the ActiveMQ is started directly, e.g. with "activemq.bat start". But if the Active

Re: Clarification of temp usage

Ok. Thank you. That explains the behaviour I´v seen... -- View this message in context: http://activemq.2283324.n4.nabble.com/Clarification-of-temp-usage-tp4711305p4711422.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Clarification of temp usage

Hello. I have a question regarding the ActiveMQ temp usage. (The ActiveMQ version is 5.10.0 but also checked with latest 5.13.2; as storage I´ve tested with KahaDb and mKahadb) In our system we have some queues and topics. The topics has persistent messages; the queues has combinations of persisten