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
Producers to our kafka brokers are failing to connect because they are receiving the internal mesos hostnames during the kafka negotiation, which are not publicly addressable from outside of our bare metal mesos cluster.
This seems to be a result of the patch from #22 (which seems to be related to internal communication between brokers on VMs).
We've implemented a simple fix by modifying Scheduler.scala with the following line after the host.name is set:
advertised.host.name" -> java.net.InetAddress.getByName(offer.getHostname).getHostAddress
Manually setting the advertised-hostname is a bad option, since brokers may automatically move around the cluster after the stickiness-period.
If there are cases where using this setting is not desirable (maybe that VM use case in #22 ?), it seems to me like the framework should provide a configuration option to determine what type of advertised hostname is needed.
Thanks.
The text was updated successfully, but these errors were encountered:
Producers to our kafka brokers are failing to connect because they are receiving the internal mesos hostnames during the kafka negotiation, which are not publicly addressable from outside of our bare metal mesos cluster.
This seems to be a result of the patch from #22 (which seems to be related to internal communication between brokers on VMs).
We've implemented a simple fix by modifying Scheduler.scala with the following line after the host.name is set:
advertised.host.name" -> java.net.InetAddress.getByName(offer.getHostname).getHostAddress
This seems to better match the default behavior that Kafka would use if the host.name were not set to the mesos offer host name (see http://kafka.apache.org/090/documentation.html#brokerconfigs).
Manually setting the advertised-hostname is a bad option, since brokers may automatically move around the cluster after the stickiness-period.
If there are cases where using this setting is not desirable (maybe that VM use case in #22 ?), it seems to me like the framework should provide a configuration option to determine what type of advertised hostname is needed.
Thanks.
The text was updated successfully, but these errors were encountered: