You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The issue tracker is ONLY used for the go client (feature request of RocketMQ need to follow RIP process). Keep in mind, please check whether there is an existing same report before your raise a new one.
Alternately (especially if your communication is not a bug report), you can send mail to our mailing lists. We welcome any friendly suggestions, bug fixes, collaboration, and other improvements.
Please ensure that your bug report is clear and that it is complete. Otherwise, we may be unable to understand it or to reproduce it, either of which would prevent us from fixing the bug. We strongly recommend the report(bug report or feature request) could include some hints as to the following:
BUG REPORT
Please describe the issue you observed:
What did you do (The steps to reproduce)?
Enviroment has three broker-master( named broker-a broker-b broker-c) , a consumer consumes messages from the three broker normally. after i shutdown the broker-b, then start it.
What did you expect to see?
After the broker-b restarted, the consumer recover consume normally.
What did you see instead?
The consumer only consume messages from broker-a and broker-b, can't consume messages from broker-b.
Please tell us about your environment:
What is your OS?
Centos
What is your client version?
v2.1.1
What is your RocketMQ version?
4.3.2
Other information (e.g. detailed explanation, logs, related issues, suggestions on how to fix, etc):
the rocketmq-client-go has logged "the topic route info changed", the route info which want be changed to is correct .
After read the rocketmq-client-go code, i think maybe the namesrv object has the correct route info, but the consumer object can't update the routeinfo correct.
FEATURE REQUEST
Please describe the feature you are requesting.
Provide any additional detail on your proposed use case for this feature.
Indicate the importance of this issue to you (blocker, must-have, should-have, nice-to-have). Are you currently using any workarounds to address this issue?
If there are some sub-tasks using -[] for each subtask and create a corresponding issue to map to the sub task:
The issue tracker is ONLY used for the go client (feature request of RocketMQ need to follow RIP process). Keep in mind, please check whether there is an existing same report before your raise a new one.
Alternately (especially if your communication is not a bug report), you can send mail to our mailing lists. We welcome any friendly suggestions, bug fixes, collaboration, and other improvements.
Please ensure that your bug report is clear and that it is complete. Otherwise, we may be unable to understand it or to reproduce it, either of which would prevent us from fixing the bug. We strongly recommend the report(bug report or feature request) could include some hints as to the following:
BUG REPORT
Please describe the issue you observed:
What did you do (The steps to reproduce)?
Enviroment has three broker-master( named broker-a broker-b broker-c) , a consumer consumes messages from the three broker normally. after i shutdown the broker-b, then start it.
What did you expect to see?
After the broker-b restarted, the consumer recover consume normally.
What did you see instead?
The consumer only consume messages from broker-a and broker-b, can't consume messages from broker-b.
Please tell us about your environment:
Centos
v2.1.1
4.3.2
Other information (e.g. detailed explanation, logs, related issues, suggestions on how to fix, etc):
the rocketmq-client-go has logged "the topic route info changed", the route info which want be changed to is correct .
After read the rocketmq-client-go code, i think maybe the namesrv object has the correct route info, but the consumer object can't update the routeinfo correct.
FEATURE REQUEST
Please describe the feature you are requesting.
Provide any additional detail on your proposed use case for this feature.
Indicate the importance of this issue to you (blocker, must-have, should-have, nice-to-have). Are you currently using any workarounds to address this issue?
If there are some sub-tasks using -[] for each subtask and create a corresponding issue to map to the sub task:
The text was updated successfully, but these errors were encountered: