Skip to content

Infinity loop in synchronisation of priority queues #857

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 8 commits into from
Jun 27, 2016

Conversation

dcorbacho
Copy link
Contributor

This solves two of the bugs in #802, the third one can only be fixed in master as detecting a stale slave requires changes on a mnesia table.

The unit tests try to trigger the bugs in a multinode test. The invoke crash seems to be triggered consistently, but it cannot be guaranteed on any environment. Thus, the suite also contains an individual test case to force it.

Diana Corbacho added 3 commits June 21, 2016 08:23
Neither amqqueue_process, master or slave modules are aware of
the priority data expected by this function, it must be stored
and retrieved internal.
It is up to the individual implementation to decide what to erase,
i.e. priority queues have one index per priority
@michaelklishin
Copy link
Collaborator

I'm getting test failures, shared details on Slack.

@michaelklishin michaelklishin merged commit dd25bf9 into stable Jun 27, 2016
@dumbbell dumbbell deleted the rabbitmq-server-802 branch January 2, 2018 15:31
dcorbacho pushed a commit that referenced this pull request Nov 18, 2020
This value is used at listener registration and will show up in
`rabbitmq-diagnostics listeners' output.

Closes #857
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