[SERVER-38108] ServerTransactionsMetrics should synchronize access to non-atomic members Created: 13/Nov/18 Updated: 29/Oct/23 Resolved: 29/Nov/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Replication |
| Affects Version/s: | None |
| Fix Version/s: | 4.1.6 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Jack Mulrow | Assignee: | Pavithra Vetriselvan |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||
| Operating System: | ALL | ||||||||
| Sprint: | Repl 2018-12-03 | ||||||||
| Participants: | |||||||||
| Linked BF Score: | 73 | ||||||||
| Description |
|
The ServerTransactionsMetrics class is a service context decoration that maintains server-wide stats for transactions, including the opTimes of uncommitted/aborted transactions. The sets of opTimes are modified by TransactionParticipant through the TransactionMetricsObserver in several places (e.g. onPrepare) and by the ReplicationCoordinator when getting the stable timestamp. There is no internal synchronization for the lists of opTimes, so they can be concurrently modified, leading to data races. A simple fix would be to add a mutex to ServerTransactionsMetrics that protects these variables. The other member variables in the class are atomics, so they are already thread-safe. |
| Comments |
| Comment by Githook User [ 29/Nov/18 ] |
|
Author: {'name': 'Pavi Vetriselvan', 'email': 'pvselvan@umich.edu', 'username': 'pvselvan'}Message: |
| Comment by Judah Schvimer [ 13/Nov/18 ] |
| Comment by Tess Avitabile (Inactive) [ 13/Nov/18 ] |
|
The mutex acquisition under the replication coordinator mutex will go away when we stop pinning the stable timestamp, so I am not too worried about that one. |
| Comment by Andy Schwerin [ 13/Nov/18 ] |
|
I'm nervous about adding mutex acquisitions underneath the replication coordinator mutex, because that mutex is the hottest in the system. |