pants build fails: Exception in thread "main" java.lang.NoSuchFieldError: NONE

[steveha-ziprecruiter]

Here's the last part of the log:

INFO: Admin HTTP interface started on port 7655.
read 0 slugs
512   INFO  io.fsq.twofishes.util.Helpers$ - readSlugs took 0 seconds
1738  INFO  org.mongodb.driver.cluster - Cluster created with settings {hosts=[127.0.0.1:27017], mode=SINGLE, requiredClusterType=UNKNOWN, serverSelectionTimeout='30000 ms', maxWaitQueueSize=500}
Exception in thread "main" java.lang.NoSuchFieldError: NONE
        at com.mongodb.casbah.WriteConcern$.<init>(WriteConcern.scala:40)
        at com.mongodb.casbah.WriteConcern$.<clinit>(WriteConcern.scala)
        at com.mongodb.casbah.BaseImports$class.$init$(Implicits.scala:162)
        at com.mongodb.casbah.Imports$.<init>(Implicits.scala:142)
        at com.mongodb.casbah.Imports$.<clinit>(Implicits.scala)
        at com.mongodb.casbah.MongoClient.apply(MongoClient.scala:217)
        at io.fsq.twofishes.indexer.mongo.MongoGeocodeDAO$.<init>(MongoGeocodeDAO.scala:10)
        at io.fsq.twofishes.indexer.mongo.MongoGeocodeDAO$.<clinit>(MongoGeocodeDAO.scala)
        at io.fsq.twofishes.indexer.importers.geonames.GeonamesParser$.main(GeonamesParser.scala:96)
        at io.fsq.twofishes.indexer.importers.geonames.GeonamesParser.main(GeonamesParser.scala)
1848  INFO  org.mongodb.driver.connection - Opened connection [connectionId{localValue:1, serverValue:1}] to 127.0.0.1:27017
1849  INFO  org.mongodb.driver.cluster - Monitor thread successfully connected to server with description ServerDescription{address=127.0.0.1:27017, type=STANDALONE, state=CONNECTED, ok=true, version=ServerVersion{versionList=[2, 0, 4]}, minWireVersion=0, maxWireVersion=0, maxDocumentSize=16777216, roundTripTimeNanos=388042}

Once the build reaches this point, it makes no further progress. I let it run overnight and it didn't continue.

This happens with an absolutely clean start: clone the repo into an empty directory, make a new empty directory and set $HOME to the empty directory.

After cloning I run:

./src/jvm/io/fsq/twofishes/scripts/download-world.sh

I'm using this command line to do the indexes build:

./src/jvm/io/fsq/twofishes/scripts/parse.py -w --output_prefix_index -r -s -i --yes-i-am-sure -- --create_unmatched_features true

I had no trouble building two weeks ago, so I tried doing a git checkout to an earlier version of the repo, and still hit this error. I'm not sure how that's possible; I hope it's some mistake I have made.

[mateor]

Hi Steven.

We are looking into the failure. But as far as your rollback attempt went, I wonder if you possibly didn't check out far back enough.

Fsq.io commit dates are a bit misleading since these are essentially cherry-picked commits from our internal repo. Those commit dates are reflecting when they were written and landed internally. Fsq.io should probably move to some sort of tagged release.

If you try checking out to: https://github.com/foursquare/fsqio/commit/4253eab7c7983b19d779e8bee4cf248d94944ac9 does it still repro?

[steveha-ziprecruiter]

I re-ran the build, checked out as 4253eab and the build just went past the point where it was failing and seems fine. I'll let you know if the build fails later.

[mateor]

Okay, I am glad to hear that. We think we have a line on the breakage - will continue to track through this thread.

[steveha-ziprecruiter]

The build completed and I was able to run Twofishes.

[jvandew]

This has unfortunately been broken since the mongo-java-driver upgrade back in November -- these scripts are our only users of the Casbah and Salat libraries so they escaped notice. The latter does not yet have a compatible version available, though I submitted a pull request here since the changes ended up being minimal.

Once we get a little more information on a timeline there I'll get a fix pushed for this issue, either upgrading to the new version or just shading our patch and bundling it ourselves. Let me know if the above workaround is insufficient for some reason in the meantime.

[mateor]

@jvandew followed through on this and has fixed the issue. I was able to run parse.py and watched it successfully spin up the cluster's connections.

I am trial running a new release habit of creating a tag every time we update Fsq.io. So I just pushed the repo yesterday, and tagged it as fsqio-2017-02-16-1638. Assuming that this practice is continued, it would have made it easier for you to roll back in case of a breakage.