[GitHub] [rocketmq] drpmma commented on issue #5690: Proxy support remoting protocol client compatibility

[GitBox <gi...@apache.org>]

drpmma commented on issue #5690:
URL: https://github.com/apache/rocketmq/issues/5690#issuecomment-1345983603

   The queue mapping idea had been considered before, but it's not easy to maintain the queue mapping rule. 
   
   First of all, the storage of queue mapping rules is a problem. If it's stored in the broker, then the broker needs to be upgraded. So let's suppose the proxy maintains the queue mapping relationship in memory. 
   
   Let's take your example, there is a topic TopicTest, which contains broker-a{0,1,2,3} and broker-b{0,1,2,3} are mapping to broker-gateway{0,1,2,3,4,5,6,7}. 
   
   How does proxy deal with the case that the broker-a{0,1,2,3} scale to broker-a{0,1,2,3,4,5,6,7}? If the mapping is append-only, which means { broker-a{0,1,2,3}, broker-b{0,1,2,3},  broker-a{4,5,6,7} }, the rule will be different and inconsistent when proxy restart. If the mapping is  { broker-a{0,1,2,3,4,5,6,7}, broker-b{0,1,2,3} }, then the specified mapping will be changed and cause inconsistent pull behavior.
   
   If the mapping rules are stored in the broker or even other storage like a database. The brokers' scale or offline behavior will also be a big challenge in maintaining the rules which need be correct when broker scale or offline.
   
   So IMO, supporting the new version client is the simplest way to keep the original protocol semantics.


-- 
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: commits-unsubscribe@rocketmq.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org