From users-return-49340-archive-asf-public=cust-asf.ponee.io@activemq.apache.org Fri Feb 9 09:53:19 2018 Return-Path: X-Original-To: archive-asf-public@eu.ponee.io Delivered-To: archive-asf-public@eu.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by mx-eu-01.ponee.io (Postfix) with ESMTP id D8E95180654 for ; Fri, 9 Feb 2018 09:53:19 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id BE863160C4C; Fri, 9 Feb 2018 08:53:19 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 10D60160C2E for ; Fri, 9 Feb 2018 09:53:18 +0100 (CET) Received: (qmail 71029 invoked by uid 500); 9 Feb 2018 08:53:17 -0000 Mailing-List: contact users-help@activemq.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@activemq.apache.org Delivered-To: mailing list users@activemq.apache.org Received: (qmail 71003 invoked by uid 99); 9 Feb 2018 08:53:17 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 09 Feb 2018 08:53:17 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id 6A752C02AC for ; Fri, 9 Feb 2018 08:53:16 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 3.116 X-Spam-Level: *** X-Spam-Status: No, score=3.116 tagged_above=-999 required=6.31 tests=[SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.972, URI_HEX=1.313, URI_TRY_3LD=0.832] autolearn=disabled Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id fF9kw0uOy1gB for ; Fri, 9 Feb 2018 08:53:14 +0000 (UTC) Received: from n4.nabble.com (n4.nabble.com [162.253.133.72]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTP id BCBD25F17B for ; Fri, 9 Feb 2018 08:53:13 +0000 (UTC) Received: from mben.nabble.com (localhost [127.0.0.1]) by n4.nabble.com (Postfix) with ESMTP id 886321878BB88 for ; Fri, 9 Feb 2018 01:53:12 -0700 (MST) Date: Fri, 9 Feb 2018 01:53:12 -0700 (MST) From: alprausch77 To: users@activemq.apache.org Message-ID: <1518166392556-0.post@n4.nabble.com> Subject: Question about rollbackOnlyOnAsyncException (AMQ-3166) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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=C2=B4s likely that the clie= nt side transaction is already committed before(!) an exception occurs on=20 the AMQ side. In that case the TransportConnection class will no longer fin= d a transaction for the message (as it=C2=B4s already committed) and of=20 course it can=C2=B4t be rolled-back anymore. Or do I misunderstand the behaviour? My current problem is that we switched from async to sync sends because we=C2=B4ve seen some messages getting lost without "seeing" it on the clien= t=20 side. For our use-case it=C2=B4s 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.=20 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=C2=B4t see= =20 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=20 commit. Thanks. btw: we are running AMQ 5.14.5 (unfortunatelly on Windows) -- Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.htm= l