Using Travis'container architecture posted on 02 December 2015

Last year, Travis announced faster builds with container-based infrastructure and Docker.

One requirement to use such infrastructure is to disable sudo with sudo: false at the top of your .travis.yml file.

If you were installing third party software using apt-get and sudo, you can just download the .deb package, and unpack it. For RethinkDB, you can run these commands:

wget http://download.rethinkdb.com/apt/pool/precise/main/r/rethinkdb/rethinkdb_2.2.1
ar x *.deb
ar xvzf data.tar.gz

You can then find your binary in ./usr/bin. For example, this is reqlite .travis.yml:

language: node_js
sudo: false
node_js:
  - "node"
before_install:
  - wget http://download.rethinkdb.com/apt/pool/precise/main/r/rethinkdb/rethinkdb_2.2.1~0precise_amd64.deb
  - ar x *.deb
  - tar xvzf data.tar.gz
before_script:
  - ./usr/bin/rethinkdb --daemon
  - npm install
  - ./bin/reqlite --port-offset 1 &
  - sleep 10
after_script:
  - rethinkdb
notifications:
  email: false

Docker without sudo, network issues posted on 05 September 2015

If you want to run docker without using sudo, you can add yourself to the docker group.

sudo usermod -aG docker <user>

In my case (Archlinux), this was not quite enough. Starting a container would work but without internet access. The main problem was that I was not part of the network groop.

sudo usermod -aG network <user>

Then things went smoothly.

Losing connectivity after a Chrome request posted on 30 August 2015

When I upgraded my kernel from 4.0.7-2 to 4.1.4.1 (and more recently to 4.1.6-1) I had a really annoying bug and since it wasted some of my time, I hope that this post may help someone.

After my 4.1 kernel update, I would start connected to the internet. I could ping any server, use wget, but as soon as I would make a request on Chromium or Firefox, I would "lose connectivity" after a few seconds. By loosing connectivity, the pings would timeout or fail with "Destination Host Unreachable". Once of the reason I had a hard time finding the reason is that I had no errors reported by the kernel or the driver. The only way to get back a connectivity was to take down the interface and bring it back up.

Eventually, everything boiled down to my Qualcomm Atheros AR8161 driver. Increasing the MTU to 9000 fixed my problem as described on this archlinux bug

Rethinkdbdash and client side backtraces posted on 15 August 2015

A bit of context

I released rethinkdbdash 2.1.3 (and 2.1.4) a bit earlier today. This release besides adding a few missing syntaxes for 2.1 (r.union and condition.branch(...)), fixed an issue with the client-side backtraces, though to be honest, the client-side backtraces were not really working before.

If a RethinkDB query throws an error, the server will provide a backtrace and the driver will reconstruct the query and underline the broken part. For example if a table is missing you will see this error:

ReqlOpFailedError: Table `test.users` does not exist in:
r.db("test").table("users").filter(function(var_1) {
^^^^^^^^^^^^^^^^^^^^^^^^^^^                         
    return var_1("age").gt(18)
})

The query is printed back and the broken parts are highlighted. These backtraces are in my opinion of the little one of the little things that makes RethinkDB enjoyable to use. However a few queries cannot be sent to the server and therefore no backtraces are available. Because RethinkDB stores JSON document, some JavaScript values are forbidden, typically NaN and Infinity. When the driver finds a forbidden value, it used to just throw an error saying NaN cannot be converted to JSON. This is painful for two reasons:

  • The presence of NaN is an operational error and the driver should just reject the query, not throw.
  • NaN can easily propages and you basically have to inspect all possible variables. The bigger your query, the harder debugging it is.

What's new

Since 2.1.3, Rethinkdbdash now builds backtraces for these errors and will point exactly where the problem is.

var r = require('rethinkdbdash')();

var ADULT_AGE = 18;
var ADULT_AGE_US = NaN; // oops

r.db('test').table('users').merge(function(user) {
  return r.branch(
    user('location').eq('US'),
    { canDrink: user('age').gt(ADULT_AGE_US) },
    { canDrink: user('age').gt(ADULT_AGE) }
  )
}).run().then(console.log).error(function(error) {
  console.log(error);
});

What will be printed is:

ReqlRuntimeError: Cannot convert `NaN` to JSON in:
r.db("test").table("users").merge(function(var_1) {
    return r.branch(var_1("location").eq("US"), {
        canDrink: var_1("age").gt(NaN)
                                  ^^^ 
    }, {
        canDrink: var_1("age").gt(18)
    })
})

Pretty cool uh? You can pin exactly where the NaN value is.

Feedback/suggestions? Ping me on Twitter via @neumino or shoot me an email at [email protected].