[SERVER-32095] Attach client.application.name to connections created by FSM worker threads in the concurrency suite Created: 27/Nov/17  Updated: 30/Oct/23  Resolved: 06/Mar/18

Status: Closed
Project: Core Server
Component/s: Testing Infrastructure
Affects Version/s: None
Fix Version/s: 3.7.3

Type: Improvement Priority: Major - P3
Reporter: Max Hirschhorn Assignee: David Bradford (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on SERVER-32094 Add support for mongo shell to send c... Closed
Related
related to SERVER-31657 improve assert.soon function logging ... Closed
related to SERVER-81542 Improve logging in FSM suites Closed
Backwards Compatibility: Fully Compatible
Sprint: TIG 2018-02-26, TIG 2018-03-12
Participants:

 Description   

The thread id args.tid should be included as client.application.name when establishing a connection to the MongoDB deployment. This would aid in debugging failures from the concurrency suite since we'd then be able to associate log messages from mongos and/or mongod with threads from the mongo shell.



 Comments   
Comment by Githook User [ 06/Mar/18 ]

Author:

{'email': 'david.bradford@mongodb.com', 'name': 'David Bradford', 'username': 'dbradf'}

Message: SERVER-32095: Include tid when establishing a connection to MongoDB deployment in concurrency suite
Branch: master
https://github.com/mongodb/mongo/commit/3059d7f2f14ad6613827b3dd39752686baa14a64

Comment by Max Hirschhorn [ 01/Jan/18 ]

We should also consider annotating any messages logged in the mongo shell using the print() function with the FSM worker thread's tid and the server connection's thread name.

diff --git a/jstests/concurrency/fsm_libs/worker_thread.js b/jstests/concurrency/fsm_libs/worker_thread.js
index 83f0384562..7fe586f12c 100644
--- a/jstests/concurrency/fsm_libs/worker_thread.js
+++ b/jstests/concurrency/fsm_libs/worker_thread.js
@@ -84,6 +84,25 @@ var workerThread = (function() {
                 }
             }
 
+            {
+                let res = assert.commandWorked(myDB.runCommand({whatsmyuri: 1}));
+                const myUri = res.you;
+
+                res = assert.commandWorked(myDB.adminCommand({currentOp: 1, client: myUri}));
+                const threadName = res.inprog[0].desc;
+                const connectionId = res.inprog[0].connectionId;
+
+                const printOriginal = print;
+                print = function() {
+                    const printArgs = Array.from(arguments);
+                    // XXX: We reconstruct the thread name using the "connectionId" field rather
+                    // than using the "desc" field outright to work around SERVER-32498.
+                    const prefix = "!!! tid=" + args.tid + ", conn=conn" + connectionId + ":";
+                    printArgs.unshift(prefix);
+                    return printOriginal.apply(this, printArgs);
+                };
+            }
+
             if (Cluster.isReplication(args.clusterOptions)) {
                 // Operations that run after a "dropDatabase" command has been issued may fail with
                 // a "DatabaseDropPending" error response if they would create a new collection on

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