[SERVER-18482] db.currentOp(True) does not return client information on idle connections Created: 14/May/15  Updated: 25/Jan/17  Resolved: 22/May/15

Status: Closed
Project: Core Server
Component/s: Diagnostics
Affects Version/s: 3.0.2
Fix Version/s: 3.1.4

Type: Bug Priority: Major - P3
Reporter: Rod Adams Assignee: Andy Schwerin
Resolution: Done Votes: 0
Labels: ET, curop, currentop
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: JPEG File first.jpeg    
Issue Links:
Depends
Duplicate
is duplicated by SERVER-20310 db.currentOp(True) does not return cl... Closed
Related
related to SERVER-20323 db.currentOp(True) does not return op... Closed
is related to SERVER-21401 db.currentOp(true) can cause use-afte... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Participants:

 Description   

Simple Repro:

  • Spin up mongod 3.0.2, default options are fine.
  • Open five mongo shells against it.
  • db.currentOp(true) in one of them.

The entries for the four idle shells will look like:

		{
			"desc" : "conn5",
			"threadId" : "0x7fb07b80e310",
			"connectionId" : 5,
			"active" : false
		},

Perform the same steps in 2.6.9, and you get back something akin to:

		{
			"opid" : 25,
			"active" : false,
			"op" : "query",
			"ns" : "",
			"query" : {
				"isMaster" : 1,
				"forShell" : 1
			},
			"client" : "127.0.0.1:63404",
			"desc" : "conn3",
			"threadId" : "0x106e04000",
			"connectionId" : 3,
			"waitingForLock" : false,
			"numYields" : 0,
			"lockStats" : {
				"timeLockedMicros" : {
					
				},
				"timeAcquiringMicros" : {
					
				}
			}
		},

Having the client information available, even for idle connections, is quite useful in some diagnostics processes, including tracking all of the applications which are connected at any given time.



 Comments   
Comment by J Rassi [ 11/Dec/15 ]

I'm tentatively denying the v3.0 backport request for this ticket, as the risk of introducing further regressions in the affected code seems to outweigh the diagnosability benefit that the fix would yield. This bug fix would require a separate implementation for the v3.0 branch (and would depend on a separate backport for SERVER-21401), and the area of code that requires fixing is relatively fragile.

As a workaround, 3.0 users who are unable to upgrade to 3.2 should consult the mongod log file in order to determine what remote address is associated with a given user connection. For example, supposing that my currentOp output looks as follows:

> db.version()
3.0.7
> db.currentOp(true)
{
	"inprog" : [
		{
			"desc" : "conn4",
			"threadId" : "0x36d1860",
			"connectionId" : 4,
			"active" : false
		},
...

I can use the following grep invocation on the mongod log file to determine the remote address of the client where connectionId is 4:

$ grep -E 'connection accepted from [^ ]+ #4' mongod.log
2015-12-11T18:12:22.861-0500 I NETWORK  [initandlisten] connection accepted from 127.0.0.1:43642 #4 (1 connection now open)

These "connection accepted" messages are logged at log level 0 (the default log level).

Comment by Ambikesh Kumar Shukla [ 09/Sep/15 ]

when I ran db.currentOp(true) on MongoShell(2.6.9) return multiple operation Id as well that is not present in the new output (Mongo shell (3.1.4).
Please refer a attachment for output : first.jpeg

Comment by Ambikesh Kumar Shukla [ 07/Sep/15 ]

I have ran db.currentOp(true) from Mongo Shell (2.6.9) this gives more information about the client id,connection id and operation id.
But when we run same command on Mongo Shell (3.0.6) .it does not return same information as they give in Mongo Shell(2.6.9)

Comment by Rod Adams [ 22/May/15 ]

I believe that covers the issues at hand, yes.

Note: Added backport request for 3.0.

Comment by Andy Schwerin [ 22/May/15 ]

rod.adams, I've fixed this at master by adding back the "client" field, only. Is that sufficient?

New output:

{
	"inprog" : [
		{
			"desc" : "conn1",
			"threadId" : "7f11cfcf5700",
			"connectionId" : 1,
			"client" : "127.0.0.1:49771",
			"active" : false
		},
    ...

Comment by Githook User [ 22/May/15 ]

Author:

{u'username': u'andy10gen', u'name': u'Andy Schwerin', u'email': u'schwerin@mongodb.com'}

Message: SERVER-18277/SERVER-18482 Remove "_remote" field from CurOp.
Branch: master
https://github.com/mongodb/mongo/commit/d6e686859c6187df791b7f61abbb9839f7e85c9a

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