Skip to content

ARTEMIS-6362 A send refused after its duplicate id check leaves the duplicate id cache as it was - #6883

Open
grepjava wants to merge 1 commit into
apache:mainfrom
grepjava:ARTEMIS-6362
Open

grepjava wants to merge 1 commit into
apache:mainfrom
grepjava:ARTEMIS-6362

Conversation

@grepjava

@grepjava grepjava commented Nov 8, 2026

Copy link
Copy Markdown
Contributor

For a send outside a transaction, PostOfficeImpl.checkNotBridgeDuplicateID starts a transaction and calls addToCache(duplID, tx, true), which put the id in the cache at once, overwriting the oldest slot of a full cache, and registered an AddDuplicateIDOperation that deleted the new id on rollback. When routing then failed (an address full under FAIL, say), the rollback took the new id out, but the id it had overwritten was gone: sending that older message again was delivered.

Both caches now keep such an id aside, in a count of ids in flight that contains also checks, so a concurrent send of it is still a duplicate. It takes its slot in beforeCommit, once the send was routed, and a rollback just releases it, so a send that fails leaves the cache as it was. The bridge's atomicVerify goes the same way.

DuplicateDetectionTest.testRefusedSendKeepsTheIdBeforeIt uses an address with id-cache-size 1 and FAIL: "d1" is accepted, the address is filled, "d2" is refused, and once the queue is drained "d1" sent again must be dropped as a duplicate. It fails without the fix.

https://issues.apache.org/jira/browse/ARTEMIS-6362

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant