Skip to content
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

Closed
allisthere2love opened this issue Apr 8, 2016 · 1 comment

Comments

@allisthere2love
Copy link

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.

@allisthere2love
Copy link
Author

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
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant