[SERVER-22238] Convert killCursors commands to OP_KILL_CURSORS to old servers Created: 20/Jan/16 Updated: 14/Apr/16 Resolved: 02/Feb/16 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Networking, Replication |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Minor - P4 |
| Reporter: | Scott Hernandez (Inactive) | Assignee: | DO NOT USE - Backlog - Platform Team |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Backwards Compatibility: | Fully Compatible |
| Operating System: | ALL |
| Participants: |
| Description |
|
When issuing a killCursors command via the NetworkInterface of an Executor we should check the wire protocol version and downconvert from the killCursors command to the wire protocol OP_KILL_CURSORS messages for compatibility. This will also reduce logging spamming as right now every time it logs a useless message. |
| Comments |
| Comment by Scott Hernandez (Inactive) [ 20/Jan/16 ] |
|
Currently the only place this can happen in replication is for the oplog tailing cursors and this message occurred when a rollback was needed specifically. This is not a high priority at the moment but the work still needs to be done if we even foresee a requirement of a 3.0 or below server in a mixed version replica set. If this doesn't come up for 3.3/4 then we can close this. Placing in 3.3 desired for tracking. |
| Comment by J Rassi [ 20/Jan/16 ] |
|
If the log message in question is benign, I'd suggest dropping it down from log level zero or removing it entirely. |
| Comment by Adam Midvidy [ 20/Jan/16 ] |
|
as the only symptom of this is potentially higher resource usage (due to cursors sticking around until they time out) ONLY during rolling upgrade, I'm tempted to WONTFIX. To implement this we'd need to make significant changes to NetworkInterfaceASIO to allow it to handle fire-and-forget opcodes such as OP_KILL_CURSORS. Currently the logic is structured so that we always error if a reply is not received. Is this causing any stability problems during upgrade in the wild? |