Mailing-List: contact users-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@activemq.apache.org
Received-SPF: pass (athena.apache.org: domain of gary.tully@gmail.com
 designates 209.85.213.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <1396872208187-4680119.post@n4.nabble.com>
References: <1396872208187-4680119.post@n4.nabble.com>
Date: Mon, 7 Apr 2014 14:57:47 +0100
Message-ID: 
 <CAH+vQmMQt0_tjJJ_HmNR1bZ3LBy6+J6qnHDj1bwLKOC5zbb=5Q@mail.gmail.com>
Subject: Re: Broken transaction when using async send
From: Gary Tully <gary.tully@gmail.com>
To: "users@activemq.apache.org" <users@activemq.apache.org>
Content-Type: text/plain; charset=ISO-8859-1

there is a related discussion here:
https://issues.apache.org/jira/browse/AMQ-3166

my thinking is that a failure to send async should mark  the
transaction rollbackOnly so that the commit will always fail in that
event.
So you send async in the hope that all is well and the transaction
boundary gives you feedback.

If you need more immediate feedback they a sync Send is needed.
alwaysSyncSend option on the CF


On 7 April 2014 13:03, ld4711 <ext-lars.ditzel@here.com> wrote:
> In our producer we use JMS transactions to send batches of 1,000 messages to
> the queue. However, we faced lost messages without client notification in
> case of server memory limit constraints (producer flow control). The point
> is that the transactions all committed without exceptions, but messages that
> were sent after the point where the server could not store further messages
> got lost without notice.
>
> Analyzing the issue showed that we were not aware of the default
> asynchronous send mode. In consequence we did not have set an exception
> listener on the connection factory. But even after remedying that we found
> the following situation:
> 1. Set the broker memory limit to a very small value (1 MB).
> 2. Send 100 messages via producer.
> With that test setup the broker can handle 95 messages. However, due to the
> asynchronous callback the producer is able to commit the transaction BEFORE
> the callback is triggered by the server.
> In consequence it seems that asynchronous sending breaks transactions in
> ActiveMQ and should not be the default mode of processing. Am I missing
> something?
>
> Thanks,
> Lars
>
>
>
>
> --
> View this message in context: http://activemq.2283324.n4.nabble.com/Broken-transaction-when-using-async-send-tp4680119.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.


-- 
http://redhat.com
http://blog.garytully.com