[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: |
|
||||||||
| Issue Links: |
|
||||||||
| 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 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: (cherry picked from commit 52c1fe02a0cd0f64a4d97f7c1e17792b38c67ca4) |
| 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,
|
| 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: (cherry picked from commit 52c1fe02a0cd0f64a4d97f7c1e17792b38c67ca4) |
| Comment by Githook User [ 01/May/18 ] |
|
Author: {'email': 'mark.benvenuto@mongodb.com', 'name': 'Mark Benvenuto', 'username': 'markbenvenuto'}Message: |
| 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 |