[
https://issues.apache.org/jira/browse/AMQ-4533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13764271#comment-13764271
]
Wieslaw Dudek commented on AMQ-4533:
------------------------------------
During my testing today the 5.9.0.redhat-610067 resolved the
AMQ4533(kahaPendingMessages) test case using
<abortSlowAckConsumerStrategy maxSlowCount="1"/> and when put enough time to
consume all messages by adding Thread.sleep(30); before checking the queue
sizes
but after adding abortConnection="true" e.g. <abortSlowAckConsumerStrategy
maxSlowCount="1" abortConnection="true"/> the TC is failing again.
So abortConnection="true" is not working and AMQ cannot force the consumer
connections to close but only can ask them gently to be closed.
For kahaPendingMessages TC it is enough because the consumer thread is in a
good state /only too busy to process other messages/
but for another test case (AMQFreezeTest) it is not enough because being
interrupted the consumers connections are in wrong state and do not react on
the close request from AMQ broker /I guess/.
For the second test case the abortConnection="true" is necessary and for my
opinion it is why the second test case is still failing.
The logs proves the theory as you can see at the end of it, during the broker
shutdown procedure the connections are released and some consumption of the
messages proceed but this is too late as AMQ had to abort those connections
earlier during the slow consumer strategy procedure.
> 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, AMQ4533TestPatch.txt, AMQ4533TestPatch.txt,
> AMQ4533TestPatch.txt, AMQFreeze_logs.zip, 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
