[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: SERVER-27031 Remove redundant tag

Removing executor::NetowkrInterface::kMessagingPortKeepOpen redundant with transport::Session::kKeepOpen
Branch: master
https://github.com/mongodb/mongo/commit/1888d91eb161f0ae4c4d2d6e225fcb931eadd2bc

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?

Generated at Thu Feb 08 04:13:58 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.