You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by ld4711 <ex...@here.com> on 2014/04/07 14:03:28 UTC
Broken transaction when using async send
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.
Re: Broken transaction when using async send
Posted by ld4711 <ex...@here.com>.
Done, thanks.
gtully wrote
> please add your 2c to that jira and maybe vote for it to show your
> interest.
--
View this message in context: http://activemq.2283324.n4.nabble.com/Broken-transaction-when-using-async-send-tp4680119p4680158.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: Broken transaction when using async send
Posted by Gary Tully <ga...@gmail.com>.
please add your 2c to that jira and maybe vote for it to show your interest.
On 7 April 2014 15:51, ld4711 <ex...@here.com> wrote:
> That sounds good! We are looking forward for the implementation. Meanwhile we
> will be using sync mode.
>
> We would also appreciate a warning hint on the documentation pages that
> default asynchronous send mode might show that behavior under special
> circumstances. Users should be aware of that risk.
>
> Thanks,
> Lars
>
>
> gtully wrote
>> 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
>
>
>
>
>
> --
> View this message in context: http://activemq.2283324.n4.nabble.com/Broken-transaction-when-using-async-send-tp4680119p4680122.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
--
http://redhat.com
http://blog.garytully.com
Re: Broken transaction when using async send
Posted by ld4711 <ex...@here.com>.
That sounds good! We are looking forward for the implementation. Meanwhile we
will be using sync mode.
We would also appreciate a warning hint on the documentation pages that
default asynchronous send mode might show that behavior under special
circumstances. Users should be aware of that risk.
Thanks,
Lars
gtully wrote
> 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
--
View this message in context: http://activemq.2283324.n4.nabble.com/Broken-transaction-when-using-async-send-tp4680119p4680122.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: Broken transaction when using async send
Posted by Gary Tully <ga...@gmail.com>.
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 <ex...@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