[SERVER-42786] Ticket acquisition should more accurately adjust timeout for maxTimeMS Created: 12/Aug/19 Updated: 06/Dec/22 Resolved: 22/Jun/20 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Concurrency |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Suganthi Mani | Assignee: | Backlog - Storage Execution Team |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | neweng | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Storage Execution
|
| Participants: |
| Description |
|
Currently, for ticket acquisition, we don't respect the "maxTimeMS". We should do the same thing like we do it for the lock acquisition wait /prepare conflict wait . Though, TicketHolder::waitForTicketUntil() has the default smallest wait interval as 500 ms. EDIT: It's not just problem with maxTimeMs <500ms. Basically, ticket acquisition can wait up to maxTimeMs+ 500ms (default semaphore wait interval), Eg. If user sets maxTimeMs = 1005, the cmd wait for 1500ms to acquire ticket. |
| Comments |
| Comment by Eric Milkie [ 23/Aug/19 ] |
|
The problem here is that we are only polling for interrupt every 500 ms when we are blocked on a semaphore. This is in contrast to blocking on a condvar, which supports immediate detection of interruption timeouts. This means maxTimeMS detection while blocked on a semaphore can be delayed up to 500 ms later than it could be. |
| Comment by Suganthi Mani [ 22/Aug/19 ] |
|
Attached the repro script and assigning to storage execution team. |
| Comment by Ratika Gandhi [ 19/Aug/19 ] |
|
suganthi.mani, please attach the repro steps.
|