[
https://issues.apache.org/jira/browse/AMQ-4533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13690397#comment-13690397
]
Wieslaw Dudek commented on AMQ-4533:
------------------------------------
Thank you Gary for your input but apart from the fact this might be
unacceptable to decrease the performance by reducing prefetchSize from 1000 to
10 I am not sure if it is going to work. It is still failing on my local
machine and anyway it might happen that we need wait a long time to have full
prefetch queue /1000 messages assigned to “stuck” consumer/ to be released. We
could tune the prefetch for every queue but anyway we might really need some
good working timeout for aborting such consumers /to release all prefetched
messages to it/. For now the timeout is related to slow consumers only and
depends on difficult mechanism of slowness detecting which does not work if
there are not enough messages coming to a queue for some time. So most likely
it is still necessary to have a new checking mechanism whether a consumer is
still consuming messages or not.
> 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
> Attachments: AMQ4533Test.java, AMQ4533TestPatch.txt,
> AMQ4533TestPatch.txt, AMQ4533TestPatch.txt, 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
