redelivery takes place on the consumer (client side only), so from the
broker perspective the messages is seen as inflight to a consumer.

Redelivery respects order, so a message pending redelivery with a
delay will pause delivery of later messages to that consumer.

Check in jconsole (jmx stats) to see the inflight count for each
consumer. If you reduce the consumer prefetch to 0, you will only ever
have a single message pending and if it is being redelivered it will
show up on the inflight count. That should help identify what is going
on.

Also peek at https://issues.apache.org/jira/browse/AMQ-3894 - there is
a good discussion
of redelivery and blocking and ordering in the related/linked jiras
and the new broker side implementation is discussed.

On 14 September 2012 19:03, Ken DeLong <ken.del...@babycenter.com> wrote:
> We are using ActiveMQ 5.5.1 as an embedded broker in our Spring 3.1.0 
> application. We have enabled message redelivery.  From time to time, we see 
> messages that are sent to the queue, but are never delivered, or are 
> delivered hours later.  We've gone through the posts on using Spring's JMS 
> Template with ActiveMQ and think we have the proper settings.
>
> Our current theory is that perhaps when messages throw a RuntimeException, 
> and get re-enqueued for later delivery, the consumers are not released and 
> the new messages can't be delivered.  However, we can't really gather much 
> evidence to support this.
>
> I'm including  the configuration that we are using, in the hopes that someone 
> might spot something that we have got wrong.
>
> <amq:broker id="jmsBroker" useJmx="true" persistent="true"
>        brokerName="localhost" dataDirectory="${catalina.home}/data/intl2/jms"
>        start="true">
>        <amq:destinationPolicy>
>               <amq:policyMap>
>                      <amq:policyEntries>
>                            <amq:policyEntry topic=">" 
> producerFlowControl="false" memoryLimit="1mb" useCache="false">
>                                   <amq:pendingSubscriberPolicy>
>                                   <amq:vmCursor />
>                                   </amq:pendingSubscriberPolicy>
>                            </amq:policyEntry>
>                            <!-- Prefetch : 
> http://activemq.apache.org/what-is-the-prefetch-limit-for.html
>                                 Flow control: 
> http://activemq.apache.org/producer-flow-control.html
>                                 Stuck messages: 
> http://activemq.2283324.n4.nabble.com/Messages-stuck-in-queue-td3244342.html
>                                                 
> https://issues.apache.org/jira/browse/AMQ-2009
>                            -->
>                            <amq:policyEntry queue=">" 
> producerFlowControl="false" memoryLimit="1mb" useCache="false" 
> queuePrefetch="1">
>                                   <!-- Use VM cursor for better latency For 
> more information, see: http://activemq.apache.org/message-cursors.html
>                                          <pendingQueuePolicy> 
> <vmQueueCursor/> </pendingQueuePolicy> -->
>                            </amq:policyEntry>
>                      </amq:policyEntries>
>               </amq:policyMap>
>        </amq:destinationPolicy>
>        <amq:managementContext>
>               <amq:managementContext createConnector="false" />
>        </amq:managementContext>
>        <amq:persistenceAdapter>
>               <amq:kahaDB directory="${catalina.home}/data/intl2/jms/kahadb"
>                      checkForCorruptJournalFiles="true" 
> checksumJournalFiles="true"
>                      forceRecoverIndex="true" />
>        </amq:persistenceAdapter>
> </amq:broker>
>
> <!-- <bean id="jmsConnectionFactory" 
> class="org.apache.activemq.pool.PooledConnectionFactory"
>        destroy-method="stop"> -->
> <bean id="jmsConnectionFactory" 
> class="org.springframework.jms.connection.CachingConnectionFactory">
>        <property name="targetConnectionFactory">
>               <bean 
> class="org.apache.activemq.spring.ActiveMQConnectionFactory">
>                      <property name="brokerURL" value="vm://localhost" />
>                      <property name="redeliveryPolicy">
>                            <bean class="org.apache.activemq.RedeliveryPolicy">
>                                   <property name="maximumRedeliveries"    
> value="15" />
>                                   <property name="initialRedeliveryDelay" 
> value="10800000" />
>                                   <property name="redeliveryDelay"        
> value="10800000" />
>                            </bean>
>                      </property>
>               </bean>
>        </property>
> </bean>
>
> <bean id="eventServiceJmsTemplate" 
> class="org.springframework.jms.core.JmsTemplate">
>        <property name="connectionFactory" ref="jmsConnectionFactory" />
>        <property name="defaultDestination" ref="destination" />
>        <property name="pubSubDomain" value="false" />
>        <property name="deliveryPersistent" value="true" />
> </bean>
>
> <bean id="destination" class="org.apache.activemq.command.ActiveMQQueue">
>        <property name="physicalName" value="asynchQueue" />
> </bean>
>
> <bean id="destinationResolver" 
> class="org.springframework.jms.support.destination.BeanFactoryDestinationResolver"
>  />
>        <!--
>      http://activemq.apache.org/message-redelivery-and-dlq-handling.html
>      Tracing through Spring's code, it seems that it will not roll back the 
> transaction unless we set acknowledge to "transacted"
>      I tested it on integ, messages are not being redelivered with "auto", 
> but they are in "transacted" mode
>      Cache none: https://issues.apache.org/jira/browse/AMQ-2009
> -->
> <jms:listener-container connection-factory="jmsConnectionFactory"
>                            acknowledge="transacted"
>                            cache="none"
>                            concurrency="5"
>                            destination-resolver="destinationResolver">
>        <jms:listener destination="destination" 
> ref="asynchronousEventExecutor" />
> </jms:listener-container>
>
>
>
>
>
>
> ---------------------------------------------------------------------------------------
> Kenneth DeLong |  Director of Architecture, Chief Software Architect
> BabyCenter
> o: 415.344.7616
> ken.del...@babycenter.com<mailto:ken.del...@babycenter.com>
> Twitter: kenwdelong
> AIM: kenwdelong
> babycenter.com<http://babycenter.com/>
>
> like BabyCenter on Facebook<http://www.facebook.com/BabyCenter>
>



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

Reply via email to