Hide Forgot
Description of problem: There are stuck messages in following scenario: 1. Send enough number of messages to cause that some of them are paged. 2. Call list-messages operation via CLI. 3. Check that returned list does not contain any duplicates. 4. Receive all messages. Result: - In step 3 there are duplicate messages however receiver does not receive duplicates - Receiver does not receive all messages. - When you look at queue via CLI, it contains lost messages. The same messages were identified as duplicates in step 3. - Stuck messages can be received only after restart of server. - I don't see any issues if the step 2 is skipped. - I don't see any issues if there are no paged messages. - The scenario works with EAP 7.0.x Steps to Reproduce: # Download patched EAP 6.4.11 # Download test suite and run the test git clone git://git.app.eng.bos.redhat.com/jbossqe/eap-tests-hornetq.git cd eap-tests-hornetq/scripts/ git checkout master # this groovy script takes EAP 6.4.x zip and unzips to 4 directories, it also makes better "default" config, change path to EAP zip per your machine groovy -DEAP_ZIP_URL=file:///<provide_path_to_downloaded_eap_zip> PrepareServers.groovy export WORKSPACE=$PWD export JBOSS_HOME_1=$WORKSPACE/server1/jboss-eap export JBOSS_HOME_2=$WORKSPACE/server2/jboss-eap export JBOSS_HOME_3=$WORKSPACE/server3/jboss-eap export JBOSS_HOME_4=$WORKSPACE/server4/jboss-eap cd ../jboss-hornetq-testsuite/ mvn clean test -Dtest=RuntimeQueueOperationsTestCaseCli#listMessagesBeforeReceiveTest -DfailIfNoTests=false | tee log
there's a difference in implementation on TotalIterator... I even went further, and TotalIterator has even more changes now on master, to avoid some duplicates that I had. TotalIterator has a parameter for browsing, so there are further improvements on master that will get into EAP 7.next
As per discussion, this is too complex to be handled in a CP, so it will be handled upstream. For EAP 6 , you should not invoke CLI operations that could cause disruption while it is paging
*** Bug 1455235 has been marked as a duplicate of this bug. ***