[SERVER-12734] CurrentOp (inprog) fails with wrapped query ($query: {}) Created: 14/Feb/14  Updated: 15/May/15  Resolved: 15/May/15

Status: Closed
Project: Core Server
Component/s: Admin, Querying
Affects Version/s: 2.5.5
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: John Morales Assignee: Adam Midvidy
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates SERVER-7775 Make special commands (inprog, killop... Closed
Related
related to JAVA-1111 isLocked is incompatible with MongoDB... Closed
Operating System: ALL
Steps To Reproduce:

db.currentOp({$query:{}})
//or
db["$cmd.sys.inprog"].findOne({$query:{}})

Participants:

 Description   

The query passed to "$cmd.sys.inprog" doesn't like the $query wrapped query.

This is a regression in 2.5.x.

old description
Via the Java driver MongoClient, there's a method exposed `isLocked()` that checks if the given node is fsync locked (i.e., it's a 'read' operation - is does not attempt an fsync lock).

This operation was successful via a 2.4.9 mongoS. But when this is performed against 2.5.5 mongoS, the driver operation fails with the following exception:

com.mongodb.MongoException: DBClientBase::findN: transport error: mms-db1:50000 ns: admin.$cmd.sys.inprog query: { $query: {} }
	at com.mongodb.QueryResultIterator.throwOnQueryFailure(QueryResultIterator.java:213)
	at com.mongodb.QueryResultIterator.init(QueryResultIterator.java:197)
	at com.mongodb.QueryResultIterator.initFromQueryResponse(QueryResultIterator.java:175)
	at com.mongodb.QueryResultIterator.<init>(QueryResultIterator.java:64)
	at com.mongodb.DBCollectionImpl.find(DBCollectionImpl.java:78)
	at com.mongodb.DBCollectionImpl.find(DBCollectionImpl.java:59)
	at com.mongodb.DBCollection.findOne(DBCollection.java:869)
	at com.mongodb.DBCollection.findOne(DBCollection.java:843)
	at com.mongodb.DBCollection.findOne(DBCollection.java:789)
	at com.mongodb.DBCollection.findOne(DBCollection.java:778)
	at com.mongodb.Mongo.isLocked(Mongo.java:734)

The mms-db1:50000 from the trace is the primary of the first shard.
In the mms-db1:50000's mongod.log, the following message is logged:

[conn551] AssertionException handling request, closing client connection: 16810 bad query: BadValue unknown top level operator: $query

It appears to be dependent on going through the mongoS, but unclear if auth-enabled is a contributing factor.



 Comments   
Comment by J Rassi [ 15/May/15 ]

The Java driver doesn't have a dedicated "db.currentOp()" equivalent, so Java users are required to do a "$cmd.sys.inprog" find in order to get the current list of active operations. The Java driver allows users to set a read preference on a MongoClient object, in which case it wraps all find operations in $query (it may actually wrap all find operations in $query, but it doesn't particularly matter either way for this issue). The handling code in the server for reads on this namespace doesn't accept $query.

With the introduction of the currentOp command in 3.1.2 (SERVER-7775), users without a currentOp helper can run the equivalent of "db.adminCommand('currentOp')" to get the current list of active operations. The currentOp command does not need to explicitly support $query (no commands do).

Hence, I'm closing this issue as a dup of SERVER-7775.

Comment by Adam Midvidy [ 15/May/15 ]

The same behavior exists with the currentOp command as well. Aside from the special casing of {$all: true}, the input to currentOp is directly passed to a Matcher, which then causes the error.

Question: why do we want currentOp to work with $query wrapped queries? Usually these are used in conjunction with a readPreference, which seems irrelevant to currentOp IMO.

Comment by Daniel Pasette (Inactive) [ 15/May/15 ]

Adam, can you check if this ticket is obsolete because of the work you've done this cycle?

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