-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
Kong does not work when using Cassandra Cluster alongside other Cassandras #1139
Comments
I was also able to validade the problem when I've checked the cluster with default ports. There, I've found the kong keyspace created (but with no tables), although I've never used the port 9042 in contact points, just 39044. |
thibaultcha
added a commit
that referenced
this issue
Apr 11, 2016
Clusters with nodes not running on the default `9042` port couldn't be properly reached by Kong. This bumps the driver (including the fix), and adds a `port` options to the configuration. Thanks @allisthere2love for the investigation. This issue was never encountered before and my guess is because such clusters added their contact_points including the port (`x.x.x.x:9043`), and the driver could connect to it, but not to the other nodes, since it was trying `9042` on those. So it simply considered the other nodes as DOWN, and thus still works (if one doesn't check the logs and those lags are not displaying warnings, it seems like nothing is going wrong). However @allisthere2love had nodes from another C* cluster listening on `9042`, leading to inconsistencies and thus, actual errors that allowed us to track it down. As per other datastax drivers, all nodes of a cluster must listen on the same port. Fix #1139 See thibaultcha/lua-cassandra#47
thibaultcha
added a commit
to thibaultcha/lua-cassandra
that referenced
this issue
Apr 11, 2016
Clusters with nodes not running on the default `9042` port couldn't be properly reached. Thanks @allisthere2love for the investigation. This issue was never encountered before and my guess is because such clusters added their contact_points including the port (`x.x.x.x:9043`), and the driver could connect to it, but not to the other nodes, since it was trying `9042` on those. So it simply considered the other nodes as DOWN, and thus still works (if one doesn't check the logs and those lags are not displaying warnings, it seems like nothing is going wrong). However @allisthere2love had nodes from another C* cluster listening on `9042`, leading to inconsistencies and thus, actual errors that allowed us to track it down. As per other datastax drivers, all nodes of a cluster must listen on the same port. Fix #47 See Kong/kong#1139
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi, related to this issue:
thibaultcha/lua-cassandra#47
In the Kong scenario, if I have in same hosts one cluster with port 9042 and other with port 39044 (let's call it A and B), and tries to use cluster B, the following occurs:
1 - If the keyspace and all data does not exists, we get a "[ERR] Error executing migration for "core": Cassandra error: [Invalid] Keyspace 'kong' does not exist"
2 - If the DDL was already previously executed, we get a "missing column family schema_migrations error"
3 - If the cluster A and B does not have the same password, we get a "bad credentials error".
As reported in the issue above, it occurs because at some point the cassandra module falls back to default port 9042.
The text was updated successfully, but these errors were encountered: