[SERVER-33575] Remove UninterruptibleLockGuards in query code to allow interruptible lock acquisition Created: 01/Mar/18 Updated: 06/Dec/22 Resolved: 07/Feb/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Querying |
| Affects Version/s: | 3.7.3 |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Louis Williams | Assignee: | Backlog - Query Team (Inactive) |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Assigned Teams: |
Query
|
||||||||
| Participants: | |||||||||
| Description |
|
Since The following places in the query code have temporary UninterruptibleLockGuard s to prevent crashing due to inadequate exception handling: src/mongo/db/commands/mr.cpp:368 |
| Comments |
| Comment by Samyukta Lanka [ 07/Feb/19 ] |
|
tess.avitabile, none of the remaining UninterruptibleLockGuards conflict with prepare because they don't take an X or S lock. Although there is work in |
| Comment by Tess Avitabile (Inactive) [ 07/Feb/19 ] |
|
samy.lanka, can you please check whether the remaining UninterruptibleLockGuards are problematic for prepare? |
| Comment by Craig Homa [ 07/Feb/19 ] |
|
There is still some remaining work from the Query team here but if this comes up again they will address it in separate and more narrowly scoped tickets. |
| Comment by David Storch [ 06/Feb/19 ] |
|
The situation has changed since this ticket was filed:
I'm marking this ticket to be re-triaged by the query team. |
| Comment by Asya Kamsky [ 11/May/18 ] |
|
Query will investigate. |
| Comment by Dianna Hohensee (Inactive) [ 11/May/18 ] |
|
I've run into an issue with an UninterruptibleLockGuard here in document_source_cursor.cpp (ran into it via an aggregation). |