Skip to content
This repository was archived by the owner on Jul 9, 2024. It is now read-only.

Conversation

michaelklishin
Copy link
Contributor

Proposed Changes

See #37 for background. This change makes the plugin provide a much improved distribution uniformity (proven by a Chi-squared test with p-value of < 0.01 as demonstrated in #37) at the cost of most costly binding and unbinding operations. More tests and documentation updates are WIP.

Pair: @dcorbacho.

Types of Changes

  • Bug fix (non-breaking change which fixes issue Message routing distribution among queues is not uniformly random #37)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • Documentation (correction or otherwise)
  • Cosmetics (whitespace, appearance)

Checklist

  • I have read the CONTRIBUTING.md document
  • I have signed the CA (see https://cla.pivotal.io/sign/rabbitmq)
  • All tests pass locally with my changes
  • I have added tests that prove my fix is effective or that my feature works
  • I have added necessary documentation (if appropriate)
  • Any dependent changes have been merged and published in related repositories

Further Comments

Closes #37.

[#159822323]

@michaelklishin michaelklishin changed the title WIP Switch hashing algorithm to Jump Consistent Hash for more uniform distribution Switch hashing algorithm to Jump Consistent Hash for more uniform distribution Aug 20, 2018
@michaelklishin
Copy link
Contributor Author

Merging per verbal approvement from @dcorbacho.

@michaelklishin michaelklishin merged commit a554eb0 into master Aug 20, 2018
michaelklishin added a commit that referenced this pull request Aug 21, 2018
In some environments, namely our Concourse containers, with *some* iterations
of the test the value exceeds the reference value of p-value = 0.01.

This may be specific to OTP 19.3 or certain platforms. This is not
something that I can reproduce in a number of OTP 21 environments.

References #37, #38.
michaelklishin added a commit that referenced this pull request Aug 21, 2018
michaelklishin added a commit that referenced this pull request Aug 21, 2018
…reorganise tests

We still depend on the PRNG to provide a reasonably uniform distribution
of inputs (e.g. routing keys) but things pass in at least 3 different environments
reliably with 150K iterations.

Pair: @dcorbacho.

References #37, #38.
michaelklishin added a commit that referenced this pull request Aug 21, 2018
In some environments, namely our Concourse containers, with *some* iterations
of the test the value exceeds the reference value of p-value = 0.01.

This may be specific to OTP 19.3 or certain platforms. This is not
something that I can reproduce in a number of OTP 21 environments.

References #37, #38.

(cherry picked from commit d7a89cd)
michaelklishin added a commit that referenced this pull request Aug 21, 2018
References #37, #38.

(cherry picked from commit 4d49ce6)
michaelklishin added a commit that referenced this pull request Aug 21, 2018
…reorganise tests

We still depend on the PRNG to provide a reasonably uniform distribution
of inputs (e.g. routing keys) but things pass in at least 3 different environments
reliably with 150K iterations.

Pair: @dcorbacho.

References #37, #38.

(cherry picked from commit e081baa)
michaelklishin added a commit that referenced this pull request Aug 24, 2018
There can be more than one bucket per queue, so we ended up with
potential extra updates that resulted in incorrect (negative) bucket numbers.

As part of this we considered using an alternative data model:
folding two tables into one that looks like this:

exchange => map(bucket => queue)

This would greatly simplify binding management and be roughly as
efficient for routing except for one thing: updating the rest of the ring
will be a linear operation over all buckets. So that change alone
would be insufficient but remains to be an idea to improve on
in the future (e.g. by using a tree).

Pair: @dcorbacho.

References #37, #38.

[#159822323]
michaelklishin added a commit that referenced this pull request Aug 28, 2018
This implementation is significantly simpler and doesn't
perform nearly as many Mnesia operations.

Pair: @dcorbacho.

References #37, #38.

[#159822323]
michaelklishin added a commit that referenced this pull request Aug 31, 2018
There can be more than one bucket per queue, so we ended up with
potential extra updates that resulted in incorrect (negative) bucket numbers.

As part of this we considered using an alternative data model:
folding two tables into one that looks like this:

exchange => map(bucket => queue)

This would greatly simplify binding management and be roughly as
efficient for routing except for one thing: updating the rest of the ring
will be a linear operation over all buckets. So that change alone
would be insufficient but remains to be an idea to improve on
in the future (e.g. by using a tree).

Pair: @dcorbacho.

References #37, #38.

[#159822323]

(cherry picked from commit 5cab6eb)
michaelklishin added a commit that referenced this pull request Aug 31, 2018
This implementation is significantly simpler and doesn't
perform nearly as many Mnesia operations.

Pair: @dcorbacho.

References #37, #38.

[#159822323]

(cherry picked from commit 0dba5a4)
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Message routing distribution among queues is not uniformly random
2 participants