[ENTMQ-496] JDBCPersistenceAdapter; When duplicate message occur from network producer, message is stuck in DB even when enableAudit="false" Created: 18/Dec/13  Updated: 10/Mar/16  Resolved: 08/Jan/14

Status: Resolved
Project: JBoss A-MQ
Component/s: broker
Affects Version/s: JBoss A-MQ 6.0
Fix Version/s: JBoss A-MQ 6.1

Type: Bug Priority: Major
Reporter: Pat Fox Assignee: Gary Tully
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:
  • test on activemq 5.8.0.redhat-60057

Attachments: Java Source File DuplicateMessagesTrappedJDBCStoreTest.java    
Issue Links:
Related
relates to ENTMQ-444 Stuck messages in a network of broker... Resolved
Steps to Reproduce:

attaching unit test


 Description   

When duplicate message occur from network producer, message is stuck in DB even when enableAudit="false". The requirement is to use replaywhenNoConsumers=true so enabling the networkAudit feature is not an option to avoid this scenario is not feasible.Expectation: with enableAudit="false" and useCache=*false" would expect the duplicate message to be read from the DB and dispatched to the consumer - where the duplicate could be detected by consumer connection.In the attached unit test, it simulates a network duplicate message by stopping and restarting the consumerBroker after message (with message ID ending in 120) is persisted to consumerBrokerstore BUT BEFORE ack sent to the producerBroker over the network connection. When the network connection is reestablished the producerBroker resends message (with messageID ending in 120).All message are consumed as expected but we see the duplicate message remain in the DB| 2013-12-18 14:15:14,359 [main ] - DEBUG teMessagesTrappedJDBCStoreTest - ||ID||CONTAINER||MSGID_PROD||MSGID_SEQ||EXPIRATION||MSG||PRIORITY||XID|||

2013-12-18 14:15:14,360 [main ] - DEBUG teMessagesTrappedJDBCStoreTest - |121|queue://duptest.store|ID:sideshow.home-65233-1387372464704-5:1:1:1|120|0|0000012b1c0000000601017b01002949443a736964657368....f|0|null|


 Comments   
Comment by Torsten Mielke [ 19/Dec/13 ]

I think this bug could be related to ENTMQ-444.

Comment by Gary Tully [ 06/Jan/14 ]

issue at apache to get duplicates redirected to dlq where appropriate - https://issues.apache.org/jira/browse/AMQ-4952

Comment by Gary Tully [ 08/Jan/14 ]

fix for https://issues.apache.org/jira/browse/AMQ-4952 merged: 521ab64..69c5469 5.9.0.redhat-6-1-x-stable

Comment by Gary Tully [ 08/Jan/14 ]

yep. I will add a warn in the in memory map duplicate case. I want to validate that it is not a normal scenario with a valid use case.

Generated at Mon Dec 17 04:02:14 EST 2018 using Jira 7.12.1#712002-sha1:609a50578ba6bc73dbf8b05dddd7c04a04b6807c.