开启proxy时，消费者启动时，不会生成对应的重试队列

[onejimmyboy]

Which Issue(s) This PR Fixes

Fixes #7251

Brief Description

How Did You Test This Change?

使用控制台查看，生成对应的重试队列，以及对应的消费者组看到了相关的信息

[HScarb]

IMO, it's not necessary to generate pop retry on startup. When retry message revives, pop retry topic will be create automatically

[onejimmyboy]

IMO, it's not necessary to generate pop retry on startup. When retry message revives, pop retry topic will be create automaticazidong

自动生成的是：MixAll.RETRY_GROUP_TOPIC_PREFIX + cid + "" + topic;不满足有些方法的需求 public static String buildPopRetryTopic(String topic, String cid) { return MixAll.RETRY_GROUP_TOPIC_PREFIX + cid + "" + topic; }

[onejimmyboy]

@RongtongJin @ShannonDing Hi, could you please review this pr? Thanks a lot :)

[drpmma]

It seems that it is not appropriate to create retry topic in PopMessageProcessor.

For the background, the retry topic will be created when heartbeat request is sent to broker for the remoting protocol client.

https://github.com/apache/rocketmq/blob/b3acee77d0a76fffba808d7b303b15fec7eb700f/broker/src/main/java/org/apache/rocketmq/broker/processor/ClientManageProcessor.java#L183-L185

But for the gRPC Local mode, it will not invoke createTopicInSendMessageBackMethod so that the retry topic will not be created.

https://github.com/apache/rocketmq/blob/b3acee77d0a76fffba808d7b303b15fec7eb700f/proxy/src/main/java/org/apache/rocketmq/proxy/grpc/v2/client/ClientActivity.java#L109-L114

Maybe it's better to handle creating retry topic behavior in heartbeat while taking cluster mode into consideration.

[drpmma]

It seems that it is not appropriate to create retry topic in PopMessageProcessor.

For the background, the retry topic will be created when heartbeat request is sent to broker for the remoting protocol client.

https://github.com/apache/rocketmq/blob/b3acee77d0a76fffba808d7b303b15fec7eb700f/broker/src/main/java/org/apache/rocketmq/broker/processor/ClientManageProcessor.java#L183-L185

But for the gRPC Local mode, it will not invoke createTopicInSendMessageBackMethod so that the retry topic will not be created.

https://github.com/apache/rocketmq/blob/b3acee77d0a76fffba808d7b303b15fec7eb700f/proxy/src/main/java/org/apache/rocketmq/proxy/grpc/v2/client/ClientActivity.java#L109-L114

Maybe it's better to handle creating retry topic behavior in heartbeat while taking proxy mode into consideration.

But for the cluster mode, the heartbeat only has group information and doesn't know what the specific broker to create the retry topic.

[onejimmyboy]

SIMPLE_CONSUMER

[onejimmyboy]

It seems that it is not appropriate to create retry topic in PopMessageProcessor.

For the background, the retry topic will be created when heartbeat request is sent to broker for the remoting protocol client.

https://github.com/apache/rocketmq/blob/b3acee77d0a76fffba808d7b303b15fec7eb700f/broker/src/main/java/org/apache/rocketmq/broker/processor/ClientManageProcessor.java#L183-L185

But for the gRPC Local mode, it will not invoke createTopicInSendMessageBackMethod so that the retry topic will not be created.

https://github.com/apache/rocketmq/blob/b3acee77d0a76fffba808d7b303b15fec7eb700f/proxy/src/main/java/org/apache/rocketmq/proxy/grpc/v2/client/ClientActivity.java#L109-L114

Maybe it's better to handle creating retry topic behavior in heartbeat while taking cluster mode into consideration.

The reason for adding the creation of a retry queue in PopMessageProcessor is that this method automatically creates consumer groups, so this PR is to automatically create a retry queue after the consumer group is automatically created SubscriptionGroupConfig subscriptionGroupConfig = this.brokerController.getSubscriptionGroupManager().findSubscriptionGroupConfig(requestHeader.getConsumerGroup()); if (null == subscriptionGroupConfig) { response.setCode(ResponseCode.SUBSCRIPTION_GROUP_NOT_EXIST); response.setRemark(String.format("subscription group [%s] does not exist, %s", requestHeader.getConsumerGroup(), FAQUrl.suggestTodo(FAQUrl.SUBSCRIPTION_GROUP_NOT_EXIST))); return response; } String retryTopicName = MixAll.getRetryTopic(requestHeader.getConsumerGroup()); this.brokerController.getTopicConfigManager().createTopicInSendMessageBackMethod(retryTopicName, subscriptionGroupConfig.getRetryQueueNums(), PermName.PERM_WRITE | PermName.PERM_READ, requestHeader.isOrder(), requestHeader.getInitMode());

[leizhiyuan]

I personally think that you should modify the code of the dashboard instead of modifying the broker to add this topic. This topic is unnecessary.

[onejimmyboy]

I personally think that you should modify the code of the dashboard instead of modifying the broker to add this topic. This topic is unnecessary.

The dashboard has not been updated for a long time, and it feels a bit late to create it in the dashboard. Before RocketMQ 5.0, the creation retry topic was also automatically created in the broker.