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
I have confirmed that this bug belongs to the current repository, not other repositories of RocketMQ.
Runtime platform environment
No influence.
RocketMQ version
the newest version.
JDK Version
No influence.
Describe the Bug
Grpc Client will be get the error address of proxy-service, when deployed multi proxy with different port.
e.g.
proxy1: 127.0.0.1:8090 broker-a: 127.0.0.1:10911
proxy2: 127.0.0.1:8091 broker-b: 127.0.0.1:20911
If clients query the topic route info from proxy1, it will get the result as 'broker-a 127.0.0.1:8090 | broker-b 127.0.0.1:8090' or 'broker-a 127.0.0.1:8091 | broker-b 127.0.0.1:8091'.
Obviously, all broker's address's port be replaced with the same port depends on the proxy be called.
If I deployed proxy with different ip and port like '192.168.1.1:8090' and '192.168.1.2:8091', It must be throw error when I call the error address like '192.168.1.1:8091'.
Steps to Reproduce
Deploy multi proxy in different ip and port with local mode.
e.g.:
proxy1: 127.0.0.1:8090 and broker-a: 127.0.0.1:10911
Use the grpc clients connect to proxy-service like send messages or consumer messages, and view the topic route info from proxy-service.
What Did You Expect to See?
Every topic route info's broker should has the right proxy address include ip and port.
What Did You See Instead?
Maybe we should return the route info like cluster mode, just return the addresses that in client request headers.
And I think we should set this default value to 'true'.
Additional Context
No response
The text was updated successfully, but these errors were encountered:
Before Creating the Bug Report
I found a bug, not just asking a question, which should be created in GitHub Discussions.
I have searched the GitHub Issues and GitHub Discussions of this repository and believe that this is not a duplicate.
I have confirmed that this bug belongs to the current repository, not other repositories of RocketMQ.
Runtime platform environment
No influence.
RocketMQ version
the newest version.
JDK Version
No influence.
Describe the Bug
Grpc Client will be get the error address of proxy-service, when deployed multi proxy with different port.
e.g.
proxy1: 127.0.0.1:8090 broker-a: 127.0.0.1:10911
proxy2: 127.0.0.1:8091 broker-b: 127.0.0.1:20911
If clients query the topic route info from proxy1, it will get the result as
'broker-a 127.0.0.1:8090 | broker-b 127.0.0.1:8090'
or'broker-a 127.0.0.1:8091 | broker-b 127.0.0.1:8091'.
Obviously, all broker's address's port be replaced with the same port depends on the proxy be called.
If I deployed proxy with different ip and port like
'192.168.1.1:8090'
and'192.168.1.2:8091',
It must be throw error when I call the error address like'192.168.1.1:8091'.
Steps to Reproduce
Deploy multi proxy in different ip and port with local mode.
e.g.:
proxy1: 127.0.0.1:8090 and broker-a: 127.0.0.1:10911
proxy2: 127.0.0.1:8091 and broker-b: 127.0.0.1:20911
Use the grpc clients connect to proxy-service like send messages or consumer messages, and view the topic route info from proxy-service.
What Did You Expect to See?
Every topic route info's broker should has the right proxy address include ip and port.
What Did You See Instead?
Maybe we should return the route info like cluster mode, just return the addresses that in client request headers.
![image](https://private-user-images.githubusercontent.com/30173876/340195884-ea847ec4-63ca-4ad6-be9d-5e57928e6931.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MjAzOTE3MTksIm5iZiI6MTcyMDM5MTQxOSwicGF0aCI6Ii8zMDE3Mzg3Ni8zNDAxOTU4ODQtZWE4NDdlYzQtNjNjYS00YWQ2LWJlOWQtNWU1NzkyOGU2OTMxLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNDA3MDclMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjQwNzA3VDIyMzAxOVomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTVjZTg1MDBiNDU1Mjk5ODM5MGJlYjMyYjMwOTk4ODg0ZWMyN2QwMzUzYWVmNDdhMWJiYTczYmZkM2U0ZDI0OGQmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JmFjdG9yX2lkPTAma2V5X2lkPTAmcmVwb19pZD0wIn0.rCJ2ALP8WNcDkdNxHKDoBDJweQJX7ynp6KxfWsMAacw)
And I think we should set this default value to 'true'.
Additional Context
No response
The text was updated successfully, but these errors were encountered: