activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chase Seibert <ch...@bullhorn.com>
Subject uncommitted transactions preventing queue processing
Date Thu, 07 Dec 2006 21:52:42 GMT

*** 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


Mime
  • Unnamed multipart/mixed (inline, None, 0 bytes)
    • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message