• Home
  • Features
  • Pricing
  • Docs
  • Announcements
  • Sign In

thibaultcha / lua-cassandra / 1062 / 1
93%
master: 93%

Build:
DEFAULT BRANCH: master
Ran 09 Aug 2018 01:23AM UTC
Files 3
Run time 0s
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst

09 Aug 2018 01:20AM UTC coverage: 96.664%. Remained the same
LUA="lua 5.1"

push

travis-ci

web-flow
fix(cluster) use 'listen_address' for contact point in refresh()

Previously, using `coordinator.host` to add the contact point to the
LB policy means that if the user specified a hostname, then it would be
used to index this node instead of the IP address. Nothing harmful in
that except some inconsistent log messages (sometimes an IP address
shows up, other times a hostname).

Problem
-------

An issue arises however when:

1. Several Cluster instances call `:refresh()` on the same C* cluster
2. DNS round-robin is in effect for the contact point hostnames

Let's consider clusterA and clusterB, both instances of the Cluster
module. Let's also consider the following C* cluster:

    10.16.0.1 node1
    10.16.0.2 node2

And the following DNS record:

    cassandra.default.svc.cluster.local. 30    IN A    10.16.0.1
    cassandra.default.svc.cluster.local. 30    IN A    10.16.0.2

First, clusterA calls `refresh()`, with `contact_points = { "cassandra"
}`, and as a result inserts the following topology in the cluster's shm:

    cassandra:[peer info]
    10.16.0.2:[peer info]

Its LB policy now has 2 entries: `cassandra` and `10.16.0.2`.

Then, clusterB calls `refresh()` as well, with the same `contact_points`
option, and as a result first purges the cluster's shm content, before
inserting the following:

    10.16.0.1:[peer info]
    cassandra:[peer info]

Note that because of the round-robin DNS resolution, `cassandra` pointed
to `10.16.0.2` this time.

Now, when clusterA will invoke its LB policy to elect a peer for a given
query, it will eventually look for `10.16.0.2`. However, such an entry
does not exist in the cluster's shm anymore. Therefore, the following
error is returned:

    no host details for 10.16.0.2

Proposed solution
-----------------

By replacing the cache key of the peer's info in the shm from the
specified `contact_point` value (which is the user's input), to the
`listen_address... (continued)

1043 of 1079 relevant lines covered (96.66%)

1227.19 hits per line

Source Files on job 1062.1 (LUA="lua 5.1")
  • Tree
  • List 0
  • Changed 0
  • Source Changed 0
  • Coverage Changed 0
Coverage ∆ File Lines Relevant Covered Missed Hits/Line
  • Back to Build 1060
  • Travis Job 1062.1
  • 8b9fcd96 on github
  • Prev Job for LUA="lua 5.1" on master (#1059.1)
  • Next Job for LUA="lua 5.1" on master (#1063.1)
STATUS · Troubleshooting · Open an Issue · Sales · Support · CAREERS · ENTERPRISE · START FREE · SCHEDULE DEMO
ANNOUNCEMENTS · TWITTER · TOS & SLA · Supported CI Services · What's a CI service? · Automated Testing

© 2025 Coveralls, Inc