Encountering random Mongo::Error::NoServerAvailable error in specs when running Mongoid 5.2 against a single/standalone instances

[Mike Javorski]

My company is just completing the update from Mongoid 3.x to Mongoid 5.2 along with Rails. Things have generally gone well, but for an intermittent failure around server availability.

The error:

Mongo::Error::NoServerAvailable:
       No server is available matching preference: #<Mongo::ServerSelector::Primary:0x70251562886840 tag_sets=[] max_staleness=nil> using server_selection_timeout=30 and local_threshold=0.015

For our development and test environments, we run against a single/standalone instance of mongodb (ver 2.6 if that matters) on the same machine. On occasion (and randomly) an Mongo::Error::NoServerAvailable is raised. The location is random, but it seems to generally be on an action involving one of a few special case models in our app. These are models in our app in which we specify (via with(read: { mode: primary_preferred }) # or :primary ) to retrieve from the primary instance for best consistency. 

The failure seems completely random, we can have multiple spec runs with no failure, and some runs with 1 or more failures in a random piece of test code. As best we can tell, the mongodb instances does not shutdown/restart while specs are running so there must be some other contributing factor. This gives us concerns that when we go to production we could continue to experience the issue which would provide for a poor experience for users.

Would really love to find a solution for this as we've already spent 3+ weeks doing the rails and mongo upgrades

Happy to provide any other information on request. I am hoping it's just a setting that can be adjusted or the like.

Thanks

- mike

[Mike Javorski]

With some more extensive debugging (including adding logging to the mongo gem itself) we've been able to determine the cause of the issue. We were using Timecop.scale (with a high scale value) in one of our specs which was tripping up the Mongo::ServerSelector#select_server call as it sets a duration limit then checks the value of same. We've adjusted our spec and that seems to have resolved the issue for us.

I might submit a pull request (or patch or whatever) to the mongo gem to always get at least one pass through the loop before failure.

- mike

[deepak kumar]

Can you explain a bit more on this, I am facing the same issue randomly

[Mike Javorski]

Deepak:

The issue we experience was due to usage of Timecop.scale which effectively speeds up the "clock" within the ruby process. Because of the scale we were using (very high), it made the 30 second timeout for server selection go by in a tiny fraction of a second which was not enough time for the mongo code to complete it's initial connections to the databases, hence it failed with Mongo::Error::NoServerAvailable. Unless you are using Timecop.scale yourself, I suspect you have a different issue.

Hope that helps.

- mike

For reference: http://www.rubydoc.info/gems/timecop/Timecop#scale-class_method