AMQ 5.1.0 and Spring 2.5.5

[Jeff Gutierrez <JG...@norvax.com>]

I've been trying to get the AMQ 5.1.0 Broker to work with our Spring-based application. When subjected to a load of 12 messages/sec (nothing significant just something I used for load testing) the AMQ Broker actually stops receiving and distributing messages (but /admin was responsive though.) After restarting the AMQ Broker the producers and consumers started working again. Take note that the producers and consumers were NOT restarted.

I also tried the following to no avail:

    * set jms.prefetchPolicy.queuePrefetch=1
    * with out failover protocol
    * AMQ 5.0.0 client with AMQ 5.1.0 broker
    * no parameters in the URL

I initially thought that it might be related to AMQ-1927 but my AMQ broker already had producerFlowControl set to false.

https://issues.apache.org/activemq/browse/AMQ-1927

Configuration:

    * Centos (kernel 2.6.18-92)
    * Java 1.6.0_05
    * ActiveMQ 5.1.0 (java -Xmx256m -Xss128k -Xms128m -Dorg.apache.activemq.UseDedicatedTaskRunner=true)
    * Spring 2.5.5
    * Camel 1.3.0
    * JMeter (load produces messages to 3 queue with throughput of 10/sec, 1/sec, and 1/sec.)

AMQ URL used by producer: failover:(tcp://host1.internal:12345)?jms.prefetchPolicy.queuePrefetch=1&jms.redeliveryPolicy.allPrefetchValues=1&jms.redeliveryPolicy.initialRedeliveryDelay=2000&jms.redeliveryPoli
cy.maximumRedeliveries=24&jms.redeliveryPolicy.useCollisionAvoidance=true

In activemq.xml:

<broker>
<!-- Destination specific policies using destination names or wildcards -->
<destinationPolicy>
<policyMap>
<policyEntries>

<policyEntry topic=">" producerFlowControl="false" memoryLimit="1mb">
<dispatchPolicy>
<strictOrderDispatchPolicy />
</dispatchPolicy>
<subscriptionRecoveryPolicy>
<lastImageSubscriptionRecoveryPolicy />
</subscriptionRecoveryPolicy>
</policyEntry>

<policyEntry queue=">">
<dispatchPolicy>
<strictOrderDispatchPolicy />
</dispatchPolicy>
<subscriptionRecoveryPolicy>
<lastImageSubscriptionRecoveryPolicy />
</subscriptionRecoveryPolicy>
<deadLetterStrategy>
<individualDeadLetterStrategy queuePrefix="DLQ." useQueueForQueueMessages="true"/>
</deadLetterStrategy>
</policyEntry>

</policyEntries>
</policyMap>
</destinationPolicy>

<!-- The transport connectors ActiveMQ will listen to -->
<transportConnectors>
<transportConnector name="openwire" uri="tcp://host1.internal:12345" />
</transportConnectors>

<!-- Use the following to set the broker memory limit -->
<systemUsage>
<systemUsage>
<memoryUsage>
<memoryUsage limit="64 mb" percentUsageMinDelta="20" />
</memoryUsage>
<tempUsage>
<tempUsage limit="100 mb" />
</tempUsage>
<storeUsage>
<storeUsage limit="1 g" name="host1.internal" />
</storeUsage>
</systemUsage>
</systemUsage>

<!-- Use the following to configure how ActiveMQ is exposed in JMX -->
<managementContext>
<managementContext connectorPort="56789" jmxDomainName="org.apache.activemq" />
</managementContext>
</broker>
...

Thread blocked in the producer side:
"resin-tcp-connection-*:6102-9" daemon prio=10 tid=0xa7a5d400 nid=0x6946 waiting on condition [0xa68b5000..0xa68b7130]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)

    * parking to wait for <0xb0b3d848> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
      at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
      at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1925)
      at java.util.concurrent.ArrayBlockingQueue.take(ArrayBlockingQueue.java:317)

Do you guys see any issue with my configuration?

I'd appreciate any information.

Thanks,
Jeff

Privileged/Confidential Information may be contained in this message. If you are not the addressee indicated in this message (or responsible for delivery of the message to such person), you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender by reply email. Please advise immediately if you or your employer does not consent to Internet email for messages of this kind. Opinions, conclusions and other information in this message that do not relate to the official business of my firm shall be understood as neither given nor endorsed by it.