Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Enhancement] Optimize the broker's reverse notification for consumerId change #9115

Open
1 task done
yx9o opened this issue Jan 9, 2025 · 0 comments · May be fixed by #9116
Open
1 task done

[Enhancement] Optimize the broker's reverse notification for consumerId change #9115

yx9o opened this issue Jan 9, 2025 · 0 comments · May be fixed by #9116

Comments

@yx9o
Copy link
Contributor

yx9o commented Jan 9, 2025

Before Creating the Enhancement Request

  • I have confirmed that this should be classified as an enhancement rather than a bug/feature.

Summary

Hi, community
This is a reverse notification issue triggered by broker for consumerId change.

Motivation

We encountered such a problem in the online environment:
An application has 100+ clients, and each client has multiple group subscriptions. When the application is released, any node will trigger a large number of reverse notifications. When the threshold is exceeded, most of the notifications fail, and we only need the latest notification.
企业微信截图_0a642809-d3a5-446c-bc65-9d0f4ae4a500

Describe the Solution You'd Like

Our idea is to improve the real-time notification part. If there are new channels that need to be notified in the same group, we will stop the last notification and always notify with the latest channels.

Describe Alternatives You've Considered

Stop the broker's reverse notification and downgrade to the client's own balance logic processing.

Additional Context

No response

yx9o added a commit to yx9o/rocketmq that referenced this issue Jan 9, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant