The behavior you're observing is expected given your configuration, i.e.:
<address-setting match="#"> <dead-letter-address>jms.queue.DLQ</dead-letter-address> <expiry-address>jms.queue.ExpiryQueue</expiry-address> <redelivery-delay>0</redelivery-delay> <max-delivery-attempts>-1</max-delivery-attempts> <max-size-bytes>10485760</max-size-bytes> <message-counter-history-day-limit>10</message-counter-history-day-limit> <address-full-policy>BLOCK</address-full-policy> </address-setting>
If you want different behavior then you should change your <address-full-policy> or <max-size-bytes>. See the documentation for more details on these parameters.
Hi Justin ,
Thanks for the quick answer . But in my case consumer are as fast as Producer are (implemented MessageListener interface) .I believe <max-size-bytes> correspondence to max queue size then in that case 10 MB is sufficient enough space to accomodate 5k messages . Please correct me if I am wrong.
Get a thread dump from the producer when it gets stuck. That should help narrow down the problem.
also make sure you are acking your consumed messages