[SERVER-34141] Inconsistent appName in Shard Created: 26/Mar/18  Updated: 29/Oct/23  Resolved: 01/May/18

Status: Closed
Project: Core Server
Component/s: Diagnostics, Sharding, Shell
Affects Version/s: None
Fix Version/s: 3.4.17, 3.6.6, 4.0.0

Type: Bug Priority: Minor - P4
Reporter: Sergio N/A Assignee: Mark Benvenuto
Resolution: Fixed Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File appName_invalid.log     File error.json     PNG File screenshot-1.png    
Issue Links:
Backports
Related
Backwards Compatibility: Fully Compatible
Operating System: ALL
Backport Requested:
v3.6, v3.4
Sprint: Platforms 2018-05-07
Participants:

 Description   

We have around 100 applications that send appName to a MongoDB Shard and 100 that do not send appName and sometimes MongoDB shows an appName that is not the correct one.
Case 1: When we run a query in the shell sometimes takes the appName from one of the applications it is running. We tested in shell version 3.2.10 by connecting in Mongos 3.4.13 and this happened in the second query executed (the first time was without appName, the second got appName from a random application).

mongos> db.investigation_users.find({teste: 1})
mongos> db.currentOp()
 
"appName" : "fetcherperf-rt1 - Fetcher - 3.0.9"
"query" : {
        "find" : "investigation_users",
        "filter" : {
                "teste" : 1
        },
        "shardVersion" : [
                Timestamp(430, 0),
                ObjectId("5a0a72f8b1199455c0f4b3c2")
        ]
}

Case 2: appName that are no longer used appear in operations of other applications. We had configured an application with the name "devops", but then we changed it to "devops - 1.3.2". The second appName started to appear in the operations, but the "devops" also appeared even with no application sending it anymore..

The attached file is an example of a shell execution and currentOp command showed an appName of an application.



 Comments   
Comment by Githook User [ 24/Jul/18 ]

Author:

{'username': 'markbenvenuto', 'name': 'Mark Benvenuto', 'email': 'mark.benvenuto@mongodb.com'}

Message: SERVER-34141 Reset client metadata when missing in metadata

(cherry picked from commit 52c1fe02a0cd0f64a4d97f7c1e17792b38c67ca4)
Branch: v3.4
https://github.com/mongodb/mongo/commit/43fcf5b663829f9d5624b7089fbf813b42647e2c

Comment by Ramon Fernandez Marina [ 12/Jul/18 ]

lucasoares, the backport to v3.4 is being considered, but there's no definite schedule yet. We'll post an update on this ticket when we have an updated schedule. Feel free to add further details on the impact of this issue on your use case.

Regards,
Ramón.

 

Comment by Lucas [ 10/Jul/18 ]

Hello.

This will be backported to 3.4?

Thanks.

Comment by Githook User [ 29/May/18 ]

Author:

{'username': 'markbenvenuto', 'name': 'Mark Benvenuto', 'email': 'mark.benvenuto@mongodb.com'}

Message: SERVER-34141 Reset client metadata when missing in metadata

(cherry picked from commit 52c1fe02a0cd0f64a4d97f7c1e17792b38c67ca4)
Branch: v3.6
https://github.com/mongodb/mongo/commit/2d3ff7012b200b2c84069c3abd3f15f37891222a

Comment by Githook User [ 01/May/18 ]

Author:

{'email': 'mark.benvenuto@mongodb.com', 'name': 'Mark Benvenuto', 'username': 'markbenvenuto'}

Message: SERVER-34141 Reset client metadata when missing in metadata
Branch: master
https://github.com/mongodb/mongo/commit/52c1fe02a0cd0f64a4d97f7c1e17792b38c67ca4

Comment by Lucas [ 24/Apr/18 ]

Hello mark.benvenuto.

This will happen only when the client doesn't pass the metadata to MongoS? Because I had this problem even using the client metadata in the driver.

Comment by Mark Benvenuto [ 24/Apr/18 ]

MongoS will pass client metadata along only when the client driver passes client metadata to MongoS.

If a client driver does not pass client metadata to MongoS, MongoS will not pass anything to MongoD, and MongoD will use the stale information for logging things like slow queries.

The fix is to reset the in-memory state of client metadata if it is not passed by the client instead of leaving stale data in memory.

Comment by Gustavo Silva Paiva [ 24/Apr/18 ]

This happened again, while creating an index through a MongoDB GUI. The GUI doesn't even have the option to add an appName and the appName MongoDB Cloud showed was from one of our applications that is running on another machine that didn't even create the index.

Comment by Lucas [ 20/Apr/18 ]

Hello.

This issue is very important to me. I use this kind of info for diagnostic proposes and I'm getting very weird results using the appName.

I have a cluster with 11 nodes. To test this appName issue I executed a count operation using a connection with specified appName: "1.7.9". After that I saw in current operations on the router that my command was with a different appName and some shards have also a different appName even between them. The router are just taking multiple random appName's and transfering them to all shards.

I uploaded a document named "error.json" with this occurence. Different appName for the same operation is really so wrong. error.json

Generated at Thu Feb 08 04:35:41 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.