[SERVER-17951] db.currentOp() fails with read preference set Created: 09/Apr/15  Updated: 19/Dec/18  Resolved: 10/Apr/15

Status: Closed
Project: Core Server
Component/s: Diagnostics, Shell
Affects Version/s: 2.6.8
Fix Version/s: 2.6.10, 3.0.3, 3.1.2

Type: Bug Priority: Major - P3
Reporter: Ole Langbehn Assignee: Sam Kleinman (Inactive)
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Related
related to SERVER-24341 Find on admin.$cmd.sys.inprog asserts... Closed
is related to SERVER-7775 Make special commands (inprog, killop... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Backport Completed:
Steps To Reproduce:

rs_DI:PRIMARY> db.getMongo().setReadPref("primary")
rs_DI:PRIMARY> db.currentOp()
2015-04-09T09:36:51.333+0000 DBClientCursor::init call() failed
2015-04-09T09:36:51.334+0000 Error: error doing query: failed at src/mongo/shell/query.js:81
2015-04-09T09:36:51.336+0000 trying reconnect to 127.0.0.1:27017 (127.0.0.1) failed
2015-04-09T09:36:51.337+0000 reconnect 127.0.0.1:27017 (127.0.0.1) ok

Sprint: BUILD 2 04/24/15
Participants:

 Description   
Issue Status as of Apr 29, 2015

ISSUE SUMMARY
In the mongo shell, the killOp, currentOp, and fsyncUnlock operations produce errors with non-primary read preferences.

USER IMPACT
In the mongo the killOp, currentOp, and fsyncUnlock operations fail when sent with non-primary read preferences and the client disconnects. Drivers are not affected by this issue as they currently remove read preference before sending these commands.

WORKAROUNDS
Set primary read preference while running the killOp, currentOp, and fsyncUnlock operations in the shell.

AFFECTED VERSIONS
MongoDB 2.4.0 to 3.0.2

FIX VERSION
The fix is included in the 3.0.3 production release.

Original description

When I set a read preference, e.g. db.getMongo().setReadPref("primary") or db.getMongo().setReadPref("secondary"), db.currentOp() fails both on mongod and mongos.



 Comments   
Comment by Githook User [ 10/Apr/15 ]

Author:

{u'username': u'tychoish', u'name': u'Sam Kleinman', u'email': u'samk@10gen.com'}

Message: SERVER-17951: handle read preferences correctly for psudocommands
Branch: v2.6
https://github.com/mongodb/mongo/commit/1ff5c722724da743c57cd96d7f4c65eda8cbb3fc

Comment by Githook User [ 10/Apr/15 ]

Author:

{u'username': u'tychoish', u'name': u'Sam Kleinman', u'email': u'samk@10gen.com'}

Message: SERVER-17951: handle read preferences correctly for psudocommands
Branch: v3.0
https://github.com/mongodb/mongo/commit/78f8f1aaaa3161109a85aada28b9f1c1b225e870

Comment by Githook User [ 10/Apr/15 ]

Author:

{u'username': u'tychoish', u'name': u'Sam Kleinman', u'email': u'samk@10gen.com'}

Message: SERVER-17951: shell currentOp should always use primary read preference
Branch: master
https://github.com/mongodb/mongo/commit/54b410fdceb61c7ce450c190c578f1b992b81e99

Comment by Ole Langbehn [ 09/Apr/15 ]

see SERVER-17749 for a similar issue triggered by read preference.

by the way, I made sure that:

  • i used --norc
  • without/before setting read preference, I can call db.currentOp()
  • in case of the cluster running 2.6.8, that every component is in version 2.6.8
Comment by Ole Langbehn [ 09/Apr/15 ]

Just verified that this also occurs on 3.0.1 on a single instance installation (no rs, no sh)

{{$ mongo
MongoDB shell version: 3.0.1
connecting to: test
> db.getMongo().setReadPref("primary")
> db.currentOp()
2015-04-09T11:39:27.244+0200 I NETWORK DBClientCursor::init call() failed
2015-04-09T11:39:27.246+0200 E QUERY Error: error doing query: failed
at DBQuery._exec (src/mongo/shell/query.js:83:36)
at DBQuery.hasNext (src/mongo/shell/query.js:240:10)
at DBCollection.findOne (src/mongo/shell/collection.js:187:19)
at DB.currentOp (src/mongo/shell/db.js:687:33)
at (shell):1:4 at src/mongo/shell/query.js:83
2015-04-09T11:39:27.247+0200 I NETWORK trying reconnect to 127.0.0.1:27017 (127.0.0.1) failed
2015-04-09T11:39:27.247+0200 I NETWORK reconnect 127.0.0.1:27017 (127.0.0.1) ok
>}}

Generated at Thu Feb 08 03:46:05 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.