Skip to content

ARTEMIS-6179 Fix deleteReference/depage deadlock - #6607

Open
clebertsuconic wants to merge 1 commit into
apache:mainfrom
clebertsuconic:ARTEMIS-6179
Open

ARTEMIS-6179 Fix deleteReference/depage deadlock#6607
clebertsuconic wants to merge 1 commit into
apache:mainfrom
clebertsuconic:ARTEMIS-6179

Conversation

@clebertsuconic

Copy link
Copy Markdown
Contributor

Removes synchronized from QueueImpl#deleteReference(). It calls iterQueue(), which acquires depageLock internally, while depage() acquires depageLock first and then enters a synchronized(this) block. The reversed lock order deadlocks QueueControl#removeMessage() against the paging executor whenever they race on an actively paging queue.

This mirrors the fix already applied to copyReference() in ARTEMIS-5376: iterQueue() already provides its own synchronization via depageLock, so the outer synchronized on deleteReference() is redundant and unsafe. Verified with
testRemoveMessageWhilstPagingAndConsuming, which reliably deadlocks without this change and passes cleanly with it.

Removes synchronized from QueueImpl#deleteReference(). It calls
iterQueue(), which acquires depageLock internally, while depage()
acquires depageLock first and then enters a synchronized(this)
block. The reversed lock order deadlocks QueueControl#removeMessage()
against the paging executor whenever they race on an actively
paging queue.

This mirrors the fix already applied to copyReference() in
ARTEMIS-5376: iterQueue() already provides its own synchronization
via depageLock, so the outer synchronized on deleteReference() is
redundant and unsafe. Verified with
testRemoveMessageWhilstPagingAndConsuming, which reliably deadlocks
without this change and passes cleanly with it.
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.

2 participants