[SERVER-33942] getMore with maxTimeMS returns "operation exceeded time limit" if concurrent blocking operation is running Created: 16/Mar/18  Updated: 29/Oct/23  Resolved: 05/Apr/18

Status: Closed
Project: Core Server
Component/s: Querying
Affects Version/s: None
Fix Version/s: 3.7.4

Type: Bug Priority: Major - P3
Reporter: Nicholas Zolnierz Assignee: Charlie Swanson
Resolution: Fixed Votes: 0
Labels: todo_in_code
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File getmore_maxtimems.js    
Issue Links:
Backports
Depends
Duplicate
is duplicated by SERVER-32399 An operation on an awaitData tailable... Closed
Related
related to SERVER-43515 Complete TODO listed in SERVER-33942 Closed
related to SERVER-44229 Complete TODO listed in SERVER-33942 Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Backport Requested:
v3.6
Sprint: Query 2018-03-26, Query 2018-04-09
Participants:
Case:
Linked BF Score: 23

 Description   

Came from investigation on BF-8367, where the awaitdata_getmore_cmd.js fails when running in parallel with compact_keeps_indexes.js. The latter performs slow operations that hold the global DB lock, and the first is expecting a getMore to time out and return a batch size of 0. Instead, the getMore fails with "exceeded time limit". Reproducible test is attached.



 Comments   
Comment by Githook User [ 05/Apr/18 ]

Author:

{'email': 'charlie.swanson@mongodb.com', 'name': 'Charlie Swanson', 'username': 'cswanson310'}

Message: SERVER-33942 Avoid setting deadline for maxTimeMS on tailable cursors
Branch: master
https://github.com/mongodb/mongo/commit/83e1a7097433b98109bbdf67f4ae3eb2421c926f

Comment by Charlie Swanson [ 30/Mar/18 ]

Bringing this into the sprint to try to prevent/mitigate build failures.

Comment by Nicholas Zolnierz [ 23/Mar/18 ]

Note as part of this fix, the blacklisted tests from SERVER-34097 should be un-blacklisted.

Comment by Charlie Swanson [ 23/Mar/18 ]

Assigning to Nick to resolve the BF, we can file a separate ticket for the real bug fix.

Comment by Andy Schwerin [ 17/Mar/18 ]

Sounds like fallout from the ticket to make lock acquisition interruptible, maybe? I wonder if await data cursors should always convert time limit exceeded errors into ok responses with whatever data has been pulled off the cursor?

Generated at Thu Feb 08 04:35:03 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.