[pop consuming] Some enhancement and bugfix when test pop consuming mode

[maixiaohai]

BUG REPORT

1. Please describe the issue you observed:

• Part A when we start the pop consumer demo to set MessageRequestMode StackOverflowError exception will be throw #3387

Exception in thread "main" org.apache.rocketmq.client.exception.MQClientException: CODE: 1  DESC: java.lang.StackOverflowError, com.google.gson.stream.JsonWriter.beforeName(JsonWriter.java:617)
For more information, please visit the url, http://rocketmq.apache.org/docs/faq/
  at org.apache.rocketmq.client.impl.MQClientAPIImpl.setMessageRequestMode(MQClientAPIImpl.java:2536)
  at org.apache.rocketmq.tools.admin.DefaultMQAdminExtImpl.setMessageRequestMode(DefaultMQAdminExtImpl.java:1062)
  at org.apache.rocketmq.tools.admin.DefaultMQAdminExt.setMessageRequestMode(DefaultMQAdminExt.java:566)
  at org.apache.rocketmq.example.simple.PopPushConsumer.switchPop(PopPushConsumer.java:46)
  at org.apache.rocketmq.example.simple.PopPushConsumer.main(PopPushConsumer.java:53)

• Part B when change the consumer group mode to pop and start a consumer, we could not see detail about the pop_retry_topic on the console, only push_retry_topic display.

• Part C messageRequestMode.json config file should be synced from master to slave in case of a new leader is elected.

• Part D ak & ck message nums are not measurable when writen into system shedule topic

2. Please tell us about your environment:
   rmq version 4.8 deployed on DLedger mode, backport all the pop consuming patches.

3. If there are some sub-tasks using -[] for each subtask and create a corresponding issue to map to the sub task:

• sub-task1-issue-number: sub-task1 description here,
• sub-task2-issue-number: sub-task2 description here,
• ...

[ShannonDing]

because of brokercontroller?

[maixiaohai]

because of brokercontroller?

transient make brokerController filed not invovled into serializazion.

you can refer to
https://stackoverflow.com/questions/17377549/best-method-in-hiding-attribute-in-json-serialization-from-java-transient-or-tr

[maixiaohai]

Part B may be caused by following code

@odbozhou

[odbozhou]

Part B may be caused by following code

@odbozhou

I will follow the above questions.

[odbozhou]

Part B may be caused by following code

@odbozhou

I will follow the above questions.

@maixiaohai

The retry topic processing methods of pop and push modes are completely different. The retry topic of push is consumed through client subscription. Therefore, SubscriptionData has a retry topic of push. The consumption of retry topic of pop is processed on the server side. There is a certain probability of consumption at the end, so when switching to pop mode, SubscriptionData will not have a retry topic

[maixiaohai]

Part B may be caused by following code

@odbozhou

I will follow the above questions.

@maixiaohai

The retry topic processing methods of pop and push modes are completely different. The retry topic of push is consumed through client subscription. Therefore, SubscriptionData has a retry topic of push. The consumption of retry topic of pop is processed on the server side. There is a certain probability of consumption at the end, so when switching to pop mode, SubscriptionData will not have a retry topic

Got it~
Just think is difficult for users to understand, and difficult for admin & sre to find the consume bottleneck~