[SERVER-38339] Better SessionKiller thread name in logs Created: 30/Nov/18  Updated: 29/Oct/23  Resolved: 26/Jan/21

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: 4.1.5
Fix Version/s: 4.9.0

Type: Improvement Priority: Minor - P4
Reporter: Randolph Tan Assignee: Alexandre Bique (Inactive)
Resolution: Fixed Votes: 0
Labels: neweng, sharding-wfbf-day
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Backwards Compatibility: Fully Compatible
Sprint: Sharding 2021-02-08
Participants:

 Description   

Currently it shows up as [thread#number]. Example:

2018-11-29T23:42:32.034+0000 I COMMAND  [thread803] killing op: 31246 as part of killing session: { id: UUID("61912b4a-9c44-4cd7-bd75-cebf2da008f1"), uid: BinData(0, 225D5B72D8EF7D8440D09A4B518E1795ED84E9BC3E28CD58A4CAF8C79DAA1A01) }



 Comments   
Comment by Githook User [ 25/Jan/21 ]

Author:

{'name': 'Alexandre Bique', 'email': 'alexandre.bique@mongodb.com'}

Message: SERVER-38339 Better SessionKiller thread name in logs
Branch: master
https://github.com/mongodb/mongo/commit/d5d4b4945fabfb772b758b95fbfa698c4448484e

Comment by Kaloian Manassiev [ 25/Jan/21 ]

Good considerations. Since there is only one instance of the "SessionKiller", this would be the best name. Even if there were more than one, they all will be doing the same thing, so nothing useful would be able to be inferred from the name anyways.

Comment by Alexandre Bique (Inactive) [ 25/Jan/21 ]

ThreadClient has two constructors, and here I'm not sure what to do:

  • the first one takes the name as a string, where I could pass "SessionKiller", I guess it is better than thread36 but if there are many instances of SessionKiller it is not very helpful either
  • the second one guess the name using getThreadName(), but in certain tests it results in "thread36" so I don't think it helps.
  • a third option would be to create a string containing both "SessionKiller" and getThreadName() but I doubt that getThreadName() will contain anything useful anyway because setThreadName() is not called earlier.
  • ServiceContext does not seem to provide a name itself, or at least it is not obvious to me.

So I conclude that the best option is to go with "SessionKiller". Please let me know if I missed something.

Comment by Kaloian Manassiev [ 22/Jan/21 ]

This is a matter of using ThreadClient in the SessionKiller's thread rather than Client::setCurrent. This will take care of setting the thread name properly.

Comment by Randolph Tan [ 03/Dec/18 ]

This is from the SessionKiller background thread, that's why it doesn't have the "conn#" name.

Comment by Kaloian Manassiev [ 03/Dec/18 ]

This message comes from killSessionsCommon and all of the calls seem to come from commands, such as killSessions. Therefore I don't think we are in control of how the thread is named. Is it possible that the commands' thread name generation is broken, causing the commands to not have conn803 in the name?

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