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
{{ message }}
This repository has been archived by the owner on Jan 19, 2023. It is now read-only.
The reporter seems to use the first advertised listener as the bootstrap server for the admin client. This can present a challenge when using docker-compose as the resolvable broker names inside the cluster and outside of the cluster may be different.
I have worked around this by starting the cluster with the advertised listeners being the docker-compose service names. This allows the HTTP reporter to function. Before starting any clients, I then dynamically change the advertised listener to the assigned IP address of each container, in order to allow external clients to produce and consume.
If we could tell the listener to use the listener specified by the inter.broker.listener.name configuration, then we avoid this issue.
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
The reporter seems to use the first advertised listener as the bootstrap server for the admin client. This can present a challenge when using docker-compose as the resolvable broker names inside the cluster and outside of the cluster may be different.
I have worked around this by starting the cluster with the advertised listeners being the docker-compose service names. This allows the HTTP reporter to function. Before starting any clients, I then dynamically change the advertised listener to the assigned IP address of each container, in order to allow external clients to produce and consume.
If we could tell the listener to use the listener specified by the inter.broker.listener.name configuration, then we avoid this issue.
The text was updated successfully, but these errors were encountered: