-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Pull queries sometimes fail in multi-node deployments #4142
Comments
@AlanConfluent is this something you are already looking at? |
#4151 is what @AlanConfluent was hitting. @mikebin Will triage. |
Yes, I have been looking into this. I'm not sure I've witnessed There are certain sporadic issued I've seen when rebalancing occurs, but I've witnessed empty results, not errors. |
@big-andy-coates did some investigation on the issue above, and determined the following:
|
Ah, yes, sorry forgot to mention that too. I wrote a fix for the above hardcoded localhost issue as well. I'll create a PR for that soon. |
I've got fixes for these three related issues... |
Fixes: confluentinc#4142 Fixes: confluentinc#4151 Fixes: confluentinc#4152 Introduces a new `inter.node.listener` that can be used to specify a URL that the node can be contacted on by other nodes. This can be different to the listeners defined in `listeners`. This can be required if `listeners` is set to a wildcard address, i.e. IPv4 `0.0.0.0` or IPv6 `[::]`, or if the node sits behind network infrastructure that requires other nodes to reach it using a different URL. If `inter.node.listener` is not set it still defaults to the first listener in `listener` config. However, it now replaces an wildcard address with `localHost`. This means inter-node comms is still possible for nodes running on the same host. Warnings are logged if the inter-node listener resolves to a loopback or local address.
* fix: pull queries should work across nodes Fixes: #4142 Fixes: #4151 Fixes: #4152 Introduces a new `inter.node.listener` that can be used to specify a URL that the node can be contacted on by other nodes. This can be different to the listeners defined in `listeners`. This can be required if `listeners` is set to a wildcard address, i.e. IPv4 `0.0.0.0` or IPv6 `[::]`, or if the node sits behind network infrastructure that requires other nodes to reach it using a different URL. If `inter.node.listener` is not set it still defaults to the first listener in `listener` config. However, it now replaces an wildcard address with `localHost`. This means inter-node comms is still possible for nodes running on the same host. Warnings are logged if the inter-node listener resolves to a loopback or local address.
Backport of confluentinc#4169 Fixes: confluentinc#4142 Fixes: confluentinc#4151 Fixes: confluentinc#4152 Introduces a new `inter.node.listener` that can be used to specify a URL that the node can be contacted on by other nodes. This can be different to the listeners defined in `listeners`. This can be required if `listeners` is set to a wildcard address, i.e. IPv4 `0.0.0.0` or IPv6 `[::]`, or if the node sits behind network infrastructure that requires other nodes to reach it using a different URL. If `inter.node.listener` is not set it still defaults to the first listener in `listener` config. However, it now replaces an wildcard address with `localHost`. This means inter-node comms is still possible for nodes running on the same host. Warnings are logged if the inter-node listener resolves to a loopback or local address. (cherry picked from commit 0ac71cf)
Backport of #4169 Fixes: #4142 Fixes: #4151 Fixes: #4152 Introduces a new `inter.node.listener` that can be used to specify a URL that the node can be contacted on by other nodes. This can be different to the listeners defined in `listeners`. This can be required if `listeners` is set to a wildcard address, i.e. IPv4 `0.0.0.0` or IPv6 `[::]`, or if the node sits behind network infrastructure that requires other nodes to reach it using a different URL. If `inter.node.listener` is not set it still defaults to the first listener in `listener` config. However, it now replaces an wildcard address with `localHost`. This means inter-node comms is still possible for nodes running on the same host. Warnings are logged if the inter-node listener resolves to a loopback or local address. (cherry picked from commit 0ac71cf)
Describe the bug
Pull queries in ksqlDB appear to fail when the key to look up exists on a different ksqlDB server than the the one which received the request. This causes sporadic failures in multi-node deployments.
To Reproduce:
docker-compose.yml
which starts 2 ksqlDB servers:Expected behaviour
Pull queries would return successfully for all available keys, whether they're local to the ksqlServer the CLI is connected to or not.
Actual behaviour
Some pull queries fail, namely those where the key is not local to the ksqlDB server receiving the request. See above for CLI output.
More detailed debug logging for a failed pull query request here:
The text was updated successfully, but these errors were encountered: