[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?

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