[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. If any user sets the command maxTimeMS < 500ms, then it's a problem.-

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.
Note that maxTimeMS is already best-effort (it requires calls into checkForInterrupt in order to terminate, and there is no guarantee the code does this frequently enough for high accuracy), so while we technically already satisfy the maxTimeMS contract, we could possibly do some things to improve it as outlined in this ticket.

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.

 

Generated at Thu Feb 08 05:01:25 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.