[SERVER-77172] "abortExpiredTransactions" thread can get stuck if it fails to checkout a session Created: 16/May/23 Updated: 23/Jan/24 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Haley Connelly | Assignee: | Backlog - Storage Execution Team |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | sharding-nyc-subteam2, sharding-nyc-subteam3 | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||
| Assigned Teams: |
Storage Execution
|
||||||||||||||||
| Participants: | |||||||||||||||||
| Story Points: | 5 | ||||||||||||||||
| Description |
|
The "abortExpiredTransactions" thread iterates over a list of expired sessions and tries to abort each one serially However, if, for some reason, one of the expired sessions cannot be checked out right away, the "abortExpiredTransactions" thread is blocked until the session can be checked out. This can potentially start expired sessions from being reaped. |
| Comments |
| Comment by Haley Connelly [ 22/Aug/23 ] |
|
jack.mulrow@mongodb.com yes, that assumption is broken when operations are volunteered to help with cache eviction and get stuck trying to evict. It looks like the root issue is summarized well in SERVER-64982. There seems to be quite a bit of WT related tickets not yet in progress. steve.kuhn@mongodb.com, do you know if WiredTiger has any plans to tackle the interruptibility/ eviction issues soon? Specifically, WT-10958 and SERVER-64982 related work? |
| Comment by Haley Connelly [ 16/May/23 ] |
|
It would be nice to make the thread more robust to when a session cannot be checked out. Just because progress cannot be made for one session, does not mean we should block all other expired sessions from being reaped. |