[SERVER-27031] De-dupe transport::Session::kKeepOpen and executor::NetworkInterface::kMessagingPortKeepOpen Created: 14/Nov/16 Updated: 05/Jun/18 Resolved: 05/Jun/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Networking, Replication |
| Affects Version/s: | None |
| Fix Version/s: | 4.1.1 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Spencer Brody (Inactive) | Assignee: | Anthony Roy |
| Resolution: | Done | Votes: | 0 |
| Labels: | neweng, service_architecture | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Backwards Compatibility: | Fully Compatible |
| Sprint: | Platforms 2018-06-18 |
| Participants: |
| Description |
|
Any incoming connection that receives a replSetHeartbeat command gets marked with the tag transport::Session::kKeepOpen, and any incoming connection that receives an ismaster command with the field "hangUpOnStepDown" set to true gets tagged with executor::NetworkInterface::kMessagingPortKeepOpen. Those tags both have the same value (1), so they both have the same affect of preventing that connection from being closed on stepdown from primary. We should dedupe these two and be consistent in how we refer to that tag/behavior. |
| Comments |
| Comment by Githook User [ 05/Jun/18 ] |
|
Author: {'name': 'Anthony Roy', 'email': 'anthony.roy@10gen.com'}Message: Removing executor::NetowkrInterface::kMessagingPortKeepOpen redundant with transport::Session::kKeepOpen |
| Comment by Spencer Brody (Inactive) [ 14/Nov/16 ] |
|
We also seem to set that tag on our outgoing connections used for reading the oplog from our sync source, which seems a little suspicious as you shouldn't have an oplog reader when you're a primary anyway (modulo catchup mode, but that line has existed since before catchup mode existed). benety.goh, do you remember why that was added? It seems to have been added in this commit EDIT: Also, according to matt.cotter TransportLayer::endAllSessions() only closes incoming connections anyway, so setting that flag on the outgoing connection for oplog reads seems like it must be a no-op? |