[
https://issues.apache.org/jira/browse/AMQ-4533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13768449#comment-13768449
]
Wieslaw Dudek commented on AMQ-4533:
------------------------------------
The configuration for ActiveMQ broker & spring consumers reflect exectly our
production configuration.
If we should change something here just let me know.
This models our 25 consumers which simulatanously process the messages on the
InputQueue
and send the receipts to the ReceiptQueue.
I agree it is very weird test case as we tried to simulate unsafe "kill"
command/or
other unexpected scenario and possibly a bug in the application which might
result in ActiveMQ or queue freeze.
I am sure that the good designed software and normal processing is working
perfectly until something unusual happened
or a bug in code. It is a very rare case when we have to remove all the
messages/and restart all applications
to let AMQ keep working but if it happens it is very serious outage.
In some our testing after upgrading to AMQ 5.8 we have experienced worse
scenario yet
when even restarting of AMQ and consumers did not help to keep processing.
We will keep trying to recreate the scenario as the upgrading does not
eliminate the "freezes"
and it is very serious issue.
What we do here is we put messages to INPUT_QUEUE and the 25 consumers, this
time configured to use spring,
consume them putting a receipt to RECEIPT_QUEUE.
Next we have consumers which consume the messages from RECEIPT_QUEUE.
So after TC ends both INPUT_QUEUE & RECEIPT_QUEUE should be empty.
If not it indicates some freeze or TC ended too fast /we could give some sleep
option to give a chance for AMQ
to consume the messages/.
> Messages stuck in queue with redelivered=true
> ---------------------------------------------
>
> Key: AMQ-4533
> URL: https://issues.apache.org/jira/browse/AMQ-4533
> Project: ActiveMQ
> Issue Type: Bug
> Components: JMS client
> Affects Versions: 5.7.0
> Environment: Fuse Message Broker 5.7.0
> Reporter: Jason Shepherd
> Assignee: Timothy Bish
> Fix For: 5.9.0
>
> Attachments: AMQ4533_logs.ZIP, AMQ4533Test.java, AMQ4533-Test.patch,
> AMQ4533-Test.patch, AMQ4533-Test.patch, AMQ4533-Test.patch,
> AMQ4533-Test.patch, AMQ4533TestPatch.txt, AMQ4533TestPatch.txt,
> AMQ4533TestPatch.txt, AMQFreezeFailingTest.zip, AMQFreeze_logs.zip,
> AMQFreezeTest.patch, AMQFreezeTest.zip, kahaPendingMessages.zip
>
>
> We're getting message stuck in queues with the
> redelivery flag set to true.
> We used the following test model: put every 1 second 50 messages
> sequentially, and after that, the rest of 1000 msgs quickly to INPUT_QUEUE
> and
> while starting 25 listeners cosuming from INPUT_QUEUE, which takes about 30
> seconds to move the message to RECEIPT_QUEUE, 10 other listeners on
> RECEIPT_QUEUE consume and counts them.
> We tried making one of the consumer slow by setting the
> processing time to 100000 seconds (sleep) and putting a heavy load in
> 500 threads every 1 ms to some other queues the same time.
> Our test case is attached, you might need to install some dependencies
> to the local maven repository manually:
> mvn install:install-file -DgroupId=org.apache.activemq
> -DartifactId=activemq-core -Dversion=5.7.0-fuse-71-047 -Dpackaging=jar
> -Dfile=activemq-core-5.7.0.fuse-71-047.jar
> mvn install:install-file -DgroupId=org.apache.kahadb
> -DartifactId=kahadb -Dversion=5.7.0-fuse-71-047 -Dpackaging=jar
> -Dfile=kahadb-5.7.0.fuse-71-047.jar
> mvn install:install-file
> -DgroupId=org.apache.geronimo.management.specs
> -DartifactId=geronimo-j2ee-management_1.1_spec -Dversion=1.0.1
> -Dpackaging=jar -Dfile=geronimo-j2ee-management_1.1_spec-1.0.1.jar
> mvn install:install-file -DgroupId=org.apache.activemq.pool
> -DartifactId=activemq-pool -Dversion=5.7.0-fuse-71-047 -Dpackaging=jar
> -Dfile=activemq-pool-5.7.0.fuse-71-047.jar
> To run the test, simply use the Maven test target:
> mvn clean test
> If the problem occurs the you'll get a message like this in the test
> results, (target/surefire-reports):
> java.lang.AssertionError: Still messages in InputQueue expected:<0>
> but was:<365>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
