-
Type:
Bug
-
Resolution: Done
-
Priority:
Major - P3
-
Affects Version/s: 2.1.1
-
Component/s: None
-
Labels:None
We recently started using the Database#collection_names method. It's necessary for WiredTiger setups which don't have a system.namespaces collection (which was our old way of getting collection names.)
In any case, we started seeing that exception, here's the stack trace.
vendor/bundle/ruby/2.1.0/gems/mongo-2.1.1/lib/mongo/database/view.rb:57:in `block in collection_names': undefined method `sub' for nil:NilClass (NoMethodError) from vendor/bundle/ruby/2.1.0/gems/mongo-2.1.1/lib/mongo/cursor.rb:78:in `block in each' from vendor/bundle/ruby/2.1.0/gems/mongo-2.1.1/lib/mongo/cursor.rb:78:in `each' from vendor/bundle/ruby/2.1.0/gems/mongo-2.1.1/lib/mongo/cursor.rb:78:in `each' from vendor/bundle/ruby/2.1.0/gems/mongo-2.1.1/lib/mongo/database/view.rb:55:in `each' from vendor/bundle/ruby/2.1.0/gems/mongo-2.1.1/lib/mongo/database/view.rb:55:in `collect' from vendor/bundle/ruby/2.1.0/gems/mongo-2.1.1/lib/mongo/database/view.rb:55:in `collection_names' from vendor/bundle/ruby/2.1.0/gems/mongo-2.1.1/lib/mongo/database.rb:112:in `collection_names' from app/models/mongodb/database.rb:55:in `collections' from app/controllers/mongodb/collections_controller.rb:3:in `index' from vendor/bundle/ruby/2.1.0/gems/actionpack-4.2.4/lib/action_controller/metal/implicit_render.rb:4:in `send_action' from vendor/bundle/ruby/2.1.0/gems/actionpack-4.2.4/lib/abstract_controller/base.rb:198:in `process_action' from vendor/bundle/ruby/2.1.0/gems/actionpack-4.2.4/lib/action_controller/metal/rendering.rb:10:in `process_action' from vendor/bundle/ruby/2.1.0/gems/actionpack-4.2.4/lib/abstract_controller/callbacks.rb:20:in `block in process_action' from vendor/bundle/ruby/2.1.0/gems/activesupport-4.2.4/lib/active_support/callbacks.rb:117:in `call' from vendor/bundle/ruby/2.1.0/gems/activesupport-4.2.4/lib/active_support/callbacks.rb:117:in `call' from vendor/bundle/ruby/2.1.0/gems/activesupport-4.2.4/lib/active_support/callbacks.rb:555:in `block (2 levels) in compile' from vendor/bundle/ruby/2.1.0/gems/activesupport-4.2.4/lib/active_support/callbacks.rb:505:in `call' from vendor/bundle/ruby/2.1.0/gems/activesupport-4.2.4/lib/active_support/callbacks.rb:505:in `call' from vendor/bundle/ruby/2.1.0/gems/activesupport-4.2.4/lib/active_support/callbacks.rb:92:in `__run_callbacks__' from vendor/bundle/ruby/2.1.0/gems/activesupport-4.2.4/lib/active_support/callbacks.rb:778:in `_run_process_action_callbacks' from vendor/bundle/ruby/2.1.0/gems/activesupport-4.2.4/lib/active_support/callbacks.rb:81:in `run_callbacks' from vendor/bundle/ruby/2.1.0/gems/actionpack-4.2.4/lib/abstract_controller/callbacks.rb:19:in `process_action' from vendor/bundle/ruby/2.1.0/gems/actionpack-4.2.4/lib/action_controller/metal/rescue.rb:29:in `process_action' from vendor/bundle/ruby/2.1.0/gems/actionpack-4.2.4/lib/action_controller/metal/instrumentation.rb:32:in `block in process_action' from vendor/bundle/ruby/2.1.0/gems/activesupport-4.2.4/lib/active_support/notifications.rb:164:in `block in instrument'
It seems to happen without any particular database name.
Could it be that the database was removed at some point, but the Database instance still existed? The monitor or whatever updates that "info" hash
Might be a good idea to check for the existence of the database (well at least the key in that "info" hash from that line in the stacktrace) before trying to call sub on it.