You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by Chase Seibert <ch...@bullhorn.com> on 2006/12/07 22:52:42 UTC
uncommitted transactions preventing queue processing
*** Caveat: We are in the process of implementing our first ActiveMQ project, and we may be missing some basic configuration. ***
Our research shows that with ActiveMQ, transacted messages queued after the currently processing message will not get dequeued until that first transaction is committed. This remains true even if the current transacted message has failed once and is pending redelivery. No other messages are processed until the first redelivery is successful, or the maximumRedeliveries threshold is reached.
Our scenario involves transacted messages that do not necessarily need to be processed in the order they were inserted onto the queue. In other words, if a message listener throws an exception on a particular message, we still want the messages behind that one to get processed immediately.
This seems analogous to a previous thread "Listener freezes on redelivery ":
http://www.nabble.com/Listener-freezes-on--redelivery-tf2351835.html#a6550585
The explanation on that issue was that ActiveMQ preserves the order of the queue. In this case, subsequent messages cannot be processed until a previous one is committed in order to maintain the message order. In contacting the poster of that issue, the resolution was to use a secondary queue to reprocess failures.
Our test project:
ActiveMQ 4.1.0
Spring 2.0
JBOSS 4.0.5.GA
Java 1.5.0_08
Our code:
--- applicationContext.xml ---
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:jee="http://www.springframework.org/schema/jee"
xsi:schemaLocation="
http://www.springframework.org/schema/jee
http://www.springframework.org/schema/jee/spring-jee.xsd
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd">
<bean id="bhIndexingMessageListenerContainer"
class="org.springframework.jms.listener.DefaultMessageListenerContainer">
<property name="concurrentConsumers" value="10"/>
<property name="pubSubDomain" value="true"/>
<property name="destination">
<jee:jndi-lookup jndi-name="activemq/queue/bullhorn_url"/>
</property>
<property name="messageListener" ref="bhISyncMessageListener" />
<property name="sessionTransacted" value="false" />
<property name="connectionFactory" ref="connectionFactory" />
</bean>
<bean id="bhISyncMessageListener" class="com.bullhorn.jms.IntelliSyncDequeue" scope="prototype"/>
<bean id="connectionFactory"
class="org.apache.activemq.ActiveMQConnectionFactory">
<property name="brokerURL" value="tcp://localhost:61616" />
<property name="redeliveryPolicy">
<bean class="org.apache.activemq.RedeliveryPolicy">
<!-- these settings will try at 0 seconds, 1 minute, 15 minutes and 3 hours 45 minutes, over 4 hours -->
<property name="initialRedeliveryDelay" value="60000"/>
<property name="backOffMultiplier" value="15"/>
<property name="useExponentialBackOff" value="true"/>
<property name="maximumRedeliveries" value="3"/>
</bean>
</property>
</bean>
</beans>
--- IntelliSyncDequeue code snippet ---
public void onMessage(Message message) {
TextMessage thisTxt = (TextMessage) message;
LOG.info("Dequeued: " + thisTxt.getText());
// my understanding is that throwing a run-time exception is one valid
// method of rolling back the transaction without implementing a custom
// transaction handler
throw new RuntimeException("This is a test error");
}
--- Results ---
We see only one "Dequeued" log entry, followed by a stack trace caused by the RuntimeException. Subsequent redelivery attempts are tried for the same message, but no other messages are processed until that message gets dequeued due to reaching maximumRedeliveries.
My question is, are we missing something about how to configure ActiveMQ to perform the desired behavior in a single queue?
-Chase
Application Developer
B U L L H O R N
Re: uncommitted transactions preventing queue processing
Posted by James Strachan <ja...@gmail.com>.
On 7 Dec 2006 16:52:42 -0500, Chase Seibert <ch...@bullhorn.com> wrote:
>
> *** Caveat: We are in the process of implementing our first ActiveMQ project, and we may be missing some basic configuration. ***
>
>
> Our research shows that with ActiveMQ, transacted messages queued after the currently processing message will not get dequeued until that first transaction is committed.
Yes. The current message must be processed & replayed until its replay
counter is reached on which time its then failed back to the broker
> This remains true even if the current transacted message has failed once and is pending redelivery. No other messages are processed until the first redelivery is successful, or the maximumRedeliveries threshold is reached.
Yes. If this were not the case then queue ordering would be broken as
soon as a redelivery occurs.
> Our scenario involves transacted messages that do not necessarily need to be processed in the order they were inserted onto the queue. In other words, if a message listener throws an exception on a particular message, we still want the messages behind that one to get processed immediately.
Either set a prefetch value of 1 (so no consumer gets more than one
message at once) or set the maximum redeliveries to 1 to avoid a bad
message blocking the next one behind. But if you don't care about
order - why not just run lots of consumers so its not a big deal if
one consumer replays a bad message a few times?
> The explanation on that issue was that ActiveMQ preserves the order of the queue. In this case, subsequent messages cannot be processed until a previous one is committed in order to maintain the message order. In contacting the poster of that issue, the resolution was to use a secondary queue to reprocess failures.
So a message that fails to be processed correctly is replayed a
configurable number of times until it is processed correctly - if it
fails to be processed correctly after all the redelivery attempts its
placed on a dead letter queue for processing later on. You don't
really need to put your own secondary queue system in place.
--
James
-------
http://radio.weblogs.com/0112098/