Allenhuangrui opened a new issue, #114:
URL: https://github.com/apache/rocketmq-apis/issues/114

   **Is your feature request related to a problem? Please describe.**
   
   `AdminSendMessageRequest` is used by management tools such as a console to 
send messages through the Admin service. For FIFO messages, the Proxy must 
select a queue with the hash algorithm associated with the original producer 
protocol. Remoting and gRPC v2 use different queue-selection algorithms.
   
   The Admin request currently has no request-scoped channel for carrying this 
protocol context. If the server falls back to a different selector, messages 
with the same message group or sharding key may be routed to different queues 
or brokers, so FIFO mutual exclusion can no longer be guaranteed.
   
   This protocol context controls how the Admin RPC is handled; it is not a 
property of the stored message.
   
   **Describe the solution you'd like**
   
   Add a request-scoped extension map to `AdminSendMessageRequest`:
   
   ```proto
   // Request-scoped extension information. Unknown entries should be ignored.
   // Known keys:
   // - protocol_type: Protocol used by the original producer (REMOTING or 
GRPC_V2).
   map<string, string> ext_info = 7;
   ```
   
   The initial key is `protocol_type`, with supported values `REMOTING` and 
`GRPC_V2`. When the map or key is absent, the server should default to the gRPC 
v2 selection logic. Unknown entries should be ignored.
   
   This is wire-compatible in both rolling-upgrade directions: old servers 
ignore field 7, while new servers receive an empty map from old clients and 
apply the default behavior. Protobuf maps do not require or support the 
`optional` label.
   
   **Describe alternatives you've considered**
   
   - Add a dedicated `protocol_type` field. This is more strongly typed and 
discoverable, but every future request-scoped routing hint would require 
another protocol field and release.
   - Put the value in `SystemProperties`. This would mix Admin RPC routing 
metadata with message metadata that may be validated, stored, or exposed to 
consumers.
   - Put the value in `user_properties`. These properties are user-controlled 
and part of the message, so they are not an appropriate channel for trusted 
request-routing hints.
   - Always use one queue-selection algorithm. This can change the established 
queue mapping for producers using the other protocol.
   
   **Additional context**
   
   Downstream Console and Proxy implementations can define a shared constant 
for the `protocol_type` key to avoid string mismatches. Stable extension keys 
should remain documented in the API definition.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to