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

thibaultcha / lua-cassandra / 1056
94%
master: 93%

Build:
Build:
LAST BUILD BRANCH: 1.5.1
DEFAULT BRANCH: master
Ran 08 Aug 2018 01:08AM UTC
Jobs 3
Files 14
Run time 3min
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

pending completion
1056

push

travis-ci

thibaultcha
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` column of the `system.local` table, do not store host... (continued)

1252 of 1641 relevant lines covered (76.29%)

713.59 hits per line

Jobs
ID Job ID Ran Files Coverage
5 1056.5 (OPENRESTY_TESTS=true CASSANDRA=3.9) 08 Aug 2018 01:09AM UTC 0
75.81
Travis Job 1056.5
6 1056.6 (OPENRESTY_TESTS=true CASSANDRA=2.2.8) 08 Aug 2018 01:08AM UTC 0
76.29
Travis Job 1056.6
7 1056.7 (OPENRESTY_TESTS=true CASSANDRA=2.1.16) 08 Aug 2018 01:12AM UTC 0
75.76
Travis Job 1056.7
Source Files on build 1056
Detailed source file information is not available for this build.
  • Back to Repo
  • Travis Build #1056
  • 76f97308 on github
  • Next Build on fix/use-listen-address-for-contact-point (#1060)
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

© 2026 Coveralls, Inc