[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: |
|
||||||||
| 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: |
| 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. |