Skip to content
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

Quorum queue replica Erlang process names can conflict between queues in different virtual hosts #11038

Open
tvhong-amazon opened this issue Apr 19, 2024 · 2 comments
Labels

Comments

@tvhong-amazon
Copy link
Contributor

tvhong-amazon commented Apr 19, 2024

Describe the bug

The internal QQ process names are of the form vhost_queue. This could cause issues when vhost and queue names contain underscores.

Reproduction steps

  1. Create a 3.13.0 broker.
  2. Create 2 vhosts called "foo" and "foo_bar"
  3. On vhost "foo", create a QQ called "bar_baz"
  4. On vhost "foo_bar", create a QQ called "baz"
  5. Observe the following error:
image

Expected behavior

User can successfully create both QQs.

Additional context

No response

@tvhong-amazon tvhong-amazon changed the title Cannot create quorum queues on vhosts due to vhost_queue process name Cannot create quorum queues on different vhosts due to vhost_queue process name Apr 19, 2024
@michaelklishin michaelklishin changed the title Cannot create quorum queues on different vhosts due to vhost_queue process name Quorum queue replica process names can conflict between queues in different virtual hosts Apr 19, 2024
@michaelklishin michaelklishin changed the title Quorum queue replica process names can conflict between queues in different virtual hosts Quorum queue replica Erlang process names can conflict between queues in different virtual hosts Apr 19, 2024
@michaelklishin
Copy link
Member

michaelklishin commented Apr 19, 2024

No matter what separator you pick, there will be a risk of such conflict. OTP system processes often use dollar signs for separators.

It's a good question what version a change like this can ship it. But given that these are process names, not replica identities (those are pairs), possibly this can go into 3.13.x.

@michaelklishin
Copy link
Member

michaelklishin commented Apr 19, 2024

@tvhong-amazon it turns out, there is an alternative strategy that's used already but only for names that are longer than 255 bytes long.

And this value is persisted as part of replica state.

So what can be done to avoid is

  1. Use the current strategy
  2. If the concatenated process name is longer than 255 bytes or we run into certain exceptions, use an alternative strategy

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 a pull request may close this issue.

2 participants