Created attachment 815027 [details] reproducer.zip There are duplicated messages with JMS bridges when AT_MOST_ONCE quality-of-service is used. Test scenario: 1. Start EAP 6.2.0.ER6 server - queue OutQueue is deployed to this server 2. Start two EAP 6.2.0.ER6 servers configured as live/backup pair in dedicated topology with shared store - queue InQueue is deployed on both of the servers - JMS bridge is deployed on both of the server - bridge sends messages from InQueue from to OutQueue to remote server started in step 1. and has AT_MOST_ONCE quality-of-service 3. Start producer which sends 1000 messages to InQueue to live 4. Kill/Shutdown live server 5. Start producer which sends 1000 messages to InQueue to backup 6. Start consumer which receives messages from OutQueue Result: Receiver gets 3000 messages. How to use reproducer.zip - following commands run in reproducer directory: 0. Under root create IP aliases (192.168.40.1-3) to your public interface: - "ifconfig eth1:0 192.168.40.1 up;ifconfig eth1:1 192.168.40.2 up;ifconfig eth1:2 192.168.40.3 up;" 1. "sh prepare.sh" - prepares servers in server{1..3} directories 2. Start servers: "sh start-server3 192.168.40.3" - target server for the JMS bridge "sh start-server1 192.168.40.1" - live server with JMS bridge "sh start-server2 192.168.40.2" - backup server with JMS bridge 3. Start producer - "sh start-producer.sh 192.168.40.1 jms/queue/InQueue 1000" 4. Kill/Shutdown "live" - server with ip 192.168.40.1 5. Start producer - "sh start-producer.sh 192.168.40.2 jms/queue/InQueue 1000" 6. Start consumer - "sh start-consumer.sh 192.168.40.3 jms/queue/OutQueue"
AT-MOST-ONCE means AT *LEAST* ONCE in British English. at_most_once can accept duplicates as documented.. so this is not a bug... if you need exactly once you have to use XA.
Not a bug.. I will let this open for a day before we close it as NOT-A-ABUG
ahh... no failure in place? I thought it was sending duplicates in case of a failure. on that case this is a blocker and needs to be fixed
I don't have privileges to make it a blocker... can someone do so... We are fixing it.
A similar issue (i.e. https://issues.jboss.org/browse/HORNETQ-1236) was fixed a few releases ago, but I see now that it only resolved the issue when <max-batch-size> for the JMS bridge was 1. However, your example used a <max-batch-size> of 10 so the problem came back. The issue should now be fixed courtesy of: https://github.com/jbertram/hornetq/commit/8f313d75e6e6b1588a735cda04e2d5c7ed7f0c6b
Based on feedback above I'm resetting dev_ack to ?.
@Clebert Can you set dev_ack to +.
modified per BZ-1022770
Verified with linked reproducer on 6.2.0.ER7 / 2.3.10. Good job guys