镜像站点 · 本页由第三方 GitHub 只读镜像提供,非 GitHub 官方站点,不接受任何登录或凭据输入。前往 github.com
Skip to content

[ISSUE #11356] fix(proxy): hash admin message groups with the data plane's queue hash - #11357

Open
iloveeyjafjalla wants to merge 1 commit into
apache:developfrom
iloveeyjafjalla:codex/admin-send-fifo-queue
Open

iloveeyjafjalla wants to merge 1 commit into
apache:developfrom
iloveeyjafjalla:codex/admin-send-fifo-queue

Conversation

@iloveeyjafjalla

Copy link
Copy Markdown
Contributor

Which Issue(s) This PR Fixes

Brief Description

AdminSendMessage resolved the write queue of a message group with
Math.floorMod(shardingKey.hashCode(), queues.size()), while the gRPC data plane resolves it with Guava's
consistent hash (SendMessageActivity.java:414). The two functions disagree for the same group and queue count —
for message group groupA-fifo over 3 writable queues, floorMod picks queue 2 and consistentHash picks
queue 0 — so a message injected through the admin surface could land on a queue that the group's producers never
write to. Per-group FIFO order only holds within a single queue, so the group's messages could be consumed out
of order, and the RPC still answered OK, so nothing told the operator the group was split.

selectQueue's javadoc states the intent ("A FIFO message must keep going to the queue its message group hashes
to") and docs/proxy-admin.md §D4 documents this path as "system properties honoured for timer / FIFO messages",
so the mapping is meant to match the data plane.

The change makes the admin path use the same hash function the data plane uses. Nothing else changes: the
no-message-group branch keeps spreading over the writable queues.

How Did You Test This Change?

New unit test ProxyAdminGrpcServiceTest#adminSendMessageRoutesMessageGroupToTheDataPlaneQueueTest: it captures
the QueueSelector the RPC hands to MessagingProcessor#sendMessage, runs it against a mocked MessageQueueView
with 3 writable queues, and asserts the selected queue is the one the data plane's formula picks for that group.
It also asserts the two formulas differ for the test key, so the test cannot silently pass if the old mapping
comes back.

Results on Temurin JDK 8 (same JDK as CI), base 9ea2ccdc2 plus this patch:

  • before the fix, the new test fails: expected:<...queueId=0...> but was:<...queueId=2...>
  • after the fix: Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
  • whole class: Tests run: 61, Failures: 0, Errors: 0, Skipped: 0 (mvn -B -ntp -pl proxy -am test -Dtest=ProxyAdminGrpcServiceTest)

This change was prepared with AI assistance (analysis, patch and test drafting); the diff and every result above
were reproduced locally by running the module's tests against the base commit and the patched tree.

…ata plane's queue hash

AdminSendMessage resolved the write queue of a message group with
Math.floorMod, while the gRPC data plane resolves it with Guava's consistent
hash (SendMessageActivity#select). The two functions disagree for the same
group and queue count, so a message injected through the admin surface could
land on a queue the group's producers never write to and split the group
across queues on the quiet, breaking its FIFO order with an OK status.

Use the same hash the data plane uses and cover the parity with a unit test on
the QueueSelector the RPC hands to MessagingProcessor#sendMessage.
Copilot AI balanced review requested due to automatic review settings October 12, 2026 02:35

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

@RockteMQ-AI RockteMQ-AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Review by github-manager-bot

Summary

Fix admin path queue hash mismatch: use Hashing.consistentHash instead of Math.floorMod so admin-injected messages land on the same queue as the data plane, preserving FIFO ordering.

Findings

  • [Info] ProxyAdminGrpcService.java:1436 — The 1-line fix correctly aligns the admin path with the data plane's hash function (SendMessageActivity.java:414). The no-message-group branch (random selection) is unchanged, which is correct.
  • [Info] ProxyAdminGrpcServiceTest.java — The new test is well-designed: it captures the QueueSelector, runs it against mocked queues, and asserts the selected queue matches the data plane's formula. The assertion that the two formulas differ for the test key (assertNotEquals) prevents silent regression if the old mapping comes back.

Suggestions

No blocking concerns. This is a minimal, targeted fix with clear problem description and solid test coverage.


Automated review by github-manager-bot

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.

[Bug] AdminSendMessage maps a FIFO message group to a different queue than the data plane

3 participants