[SERVER-50090] Include the connection ID in the abortExpiredTransactions log entry Created: 04/Aug/20 Updated: 27/Oct/23 Resolved: 12/Jun/23 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Logging |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Tomer Yakir | Assignee: | Backlog - Replication Team |
| Resolution: | Gone away | Votes: | 1 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Assigned Teams: |
Replication
|
||||
| Participants: | |||||
| Description |
|
When the abortExpiredTransactions operation is logged, it contains the following information:
It'd be helpful to add the connId as a transaction parameter so that we can correlate to a certain connection and get a better sense of which application was associated with this event. |
| Comments |
| Comment by Connie Chen [ 06/Jun/23 ] |
|
Reassigning this to the Replication team to re-triage as Gaurave is no longer at the company |
| Comment by A. Jesse Jiryu Davis [ 24/Aug/20 ] |
|
One idea is to log the application name, or application name plus additional client metadata fields like the driver version and OS, along with the aborted transaction ids. We should learn more about what would be useful to diagnose whatever issue motivated this ticket. |
| Comment by Bruce Lucas (Inactive) [ 07/Aug/20 ] |
|
Aborting expired transactions is done on a separate thread, not by a specific connection. Also I think the concept of "the" connection for a transaction isn't well defined as operations on the transaction could come from multiple connections. However for the use case that prompted this ticket I think it would be sufficient to log the connectionId of the connection that initiated the transaction. |