Skip to content

Conversation

@maxbrodin
Copy link

Fixes #648

Ensuring we have only one order of acquiring synchronization on objects consumers and recordedQueues. Having one order avoids circular wait.

…ts consumers and recordedQueues. Having one order avoids circular wait.
@pivotal-issuemaster
Copy link

@maxbrodin Please sign the Contributor License Agreement!

Click here to manually synchronize the status of this Pull Request.

See the FAQ for frequently asked questions.

@pivotal-issuemaster
Copy link

@maxbrodin Thank you for signing the Contributor License Agreement!

@michaelklishin
Copy link
Contributor

While investigating this I have found out that 1aad565 addressed this in a different place. I now wonder whether AutorecoveringConnection#maybeDeleteRecordedAutoDeleteExchange needs to acquire a lock on this.consumers.

@michaelklishin
Copy link
Contributor

michaelklishin commented Apr 22, 2020

To answer my own question: it seems to be a copy-and-paste artefact. AutorecoveringConnection#maybeDeleteRecordedAutoDeleteQueue calls AutorecoveringConnection#hasMoreConsumersOnQueue but AutorecoveringConnection#maybeDeleteRecordedAutoDeleteExchange does not.

@michaelklishin
Copy link
Contributor

So the right thing to do is to not acquire a lock on this.consumers in AutorecoveringConnection#maybeDeleteRecordedAutoDeleteExchange instead. Thank you for your time and bringing this up to our attention in the first place!

michaelklishin added a commit that referenced this pull request Apr 22, 2020
…ot need to acquire a lock on this.consumers

It most likely was a copy-paste artefact introduced back in 2013-2014.
AutorecoveringConnection.maybeDeleteRecordedAutoDeleteQueue does need
to lock this.consumers as conditional queue deletion does need to
check the number of known consumers on that queue.

1aad565 addressed a potential deadlock caused by the unsafe
order of lock acquisitions. In #648 another similar issue
was discovered which #649 tried to address by acquiring a lock
on this.consumers early.

However, exchange cleanup does not need to lock this.consumers
as it does not mutate it.

Closes #648.
@michaelklishin michaelklishin added this to the 5.9.1 milestone Apr 22, 2020
@michaelklishin michaelklishin self-assigned this Apr 22, 2020
michaelklishin added a commit that referenced this pull request Apr 22, 2020
…ot need to acquire a lock on this.consumers

It most likely was a copy-paste artefact introduced back in 2013-2014.
AutorecoveringConnection.maybeDeleteRecordedAutoDeleteQueue does need
to lock this.consumers as conditional queue deletion does need to
check the number of known consumers on that queue.

1aad565 addressed a potential deadlock caused by the unsafe
order of lock acquisitions. In #648 another similar issue
was discovered which #649 tried to address by acquiring a lock
on this.consumers early.

However, exchange cleanup does not need to lock this.consumers
as it does not mutate it.

Closes #648.

(cherry picked from commit 5c3fce8)
@maxbrodin maxbrodin deleted the 648-potential-deadlock-fix branch April 22, 2020 17:56
@acogoluegnes acogoluegnes modified the milestones: 5.9.1, 5.10.0 Apr 27, 2020
acogoluegnes pushed a commit that referenced this pull request Apr 27, 2020
…ot need to acquire a lock on this.consumers

It most likely was a copy-paste artefact introduced back in 2013-2014.
AutorecoveringConnection.maybeDeleteRecordedAutoDeleteQueue does need
to lock this.consumers as conditional queue deletion does need to
check the number of known consumers on that queue.

1aad565 addressed a potential deadlock caused by the unsafe
order of lock acquisitions. In #648 another similar issue
was discovered which #649 tried to address by acquiring a lock
on this.consumers early.

However, exchange cleanup does not need to lock this.consumers
as it does not mutate it.

Closes #648.

(cherry picked from commit 5c3fce8)
acogoluegnes pushed a commit that referenced this pull request Apr 27, 2020
…ot need to acquire a lock on this.consumers

It most likely was a copy-paste artefact introduced back in 2013-2014.
AutorecoveringConnection.maybeDeleteRecordedAutoDeleteQueue does need
to lock this.consumers as conditional queue deletion does need to
check the number of known consumers on that queue.

1aad565 addressed a potential deadlock caused by the unsafe
order of lock acquisitions. In #648 another similar issue
was discovered which #649 tried to address by acquiring a lock
on this.consumers early.

However, exchange cleanup does not need to lock this.consumers
as it does not mutate it.

Closes #648.

(cherry picked from commit 5c3fce8)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Potential deadlock in AutorecoveringConnection

4 participants