activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ken DeLong <ken.del...@babycenter.com>
Subject RE: Intermittent delayed delivery
Date Mon, 17 Sep 2012 16:12:26 GMT
We are using it as a reliable task scheduler - we submit asynchronous tasks to be executed
that don't need to be on the user's request-handling thread.  Some of these tasks involve
communication with other systems that might be down at the time.  We queue up the tasks and
retry them until they succeed so that we don't lose any.  That's why we have a 3h redelivery
delay - if the system was down, 3h should be more than enough for it to come back up (although
some of our 3rd party vendors don't always make it.  :-)


-----Original Message-----
From: Claus Ibsen [mailto:claus.ibsen@gmail.com] 
Sent: Friday, September 14, 2012 11:18 PM
To: users@activemq.apache.org
Subject: Re: Intermittent delayed delivery

The redelivery delay values seems high to me. Is this on purpose?
10800000 mills is a high value

On Fri, Sep 14, 2012 at 8:03 PM, Ken DeLong <ken.delong@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.delong@babycenter.com<mailto:ken.delong@babycenter.com>
> Twitter: kenwdelong
> AIM: kenwdelong
> babycenter.com<http://babycenter.com/>
>
> like BabyCenter on Facebook<http://www.facebook.com/BabyCenter>
>



-- 
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen

Mime
View raw message