[SERVER-57086] Do not set inherited maxTimeMSOpOnly deadline on hello command in v4.4 Created: 20/May/21  Updated: 29/Oct/23  Resolved: 05/Aug/21

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

Type: Task Priority: Major - P3
Reporter: Janna Golden Assignee: George Wangensteen
Resolution: Fixed Votes: 0
Labels: carry-over, servicearch-wfbf-day
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Depends
Backwards Compatibility: Fully Compatible
Backport Requested:
v5.0
Sprint: Service Arch 2021-07-12, Service Arch 2021-08-09
Participants:
Story Points: 3

 Description   

In v5.0 we began setting the maxTimeMSOpOnly field on internal commands, but ignore it and do not set a deadline on the opCtx for the hello command to avoid interfering with the RSM. In a mixed version cluster, nodes that are on v4.4 do not ignore this field and do set a deadline on the opCtx, causing nodes on v5.0 to see a lot of RSM failures due to MaxTimeMsExpired. We should also ignore this field for the hello command in v4.4.



 Comments   
Comment by Githook User [ 05/Aug/21 ]

Author:

{'name': 'George Wangensteen', 'email': 'george.wangensteen@mongodb.com', 'username': 'gewa24'}

Message: SERVER-57086 Do not set inherited maxTimeMSOpOnly on non-hedged commands
to servers not on 5.0
Branch: v5.0
https://github.com/mongodb/mongo/commit/21679e3ba23ce0d73678ef0f62f5a05b50176a0f

Comment by Janna Golden [ 20/May/21 ]

Yeah that's a fair point, I'd imagine we can also avoid setting maxTimeMSOpOnly if not fully upgraded and the op is not a hedged read (in v4.4 we do use this field for hedged reads).

Comment by Max Hirschhorn [ 20/May/21 ]

In addition to/instead of changing the 4.4 behavior to ignore the maxTimeMSOpOnly argument, is there a change to the 5.0 branch that could be made to prevent a 5.0 server from sending the maxTimeMSOpOnly argument to a 4.4 server?

My impression is that any upgrade from 4.4.x with x < 7 -> 5.0 would encounter this.

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