[SERVER-24574] Tag internal connections KeepOpen to avoid closing on stepdown Created: 14/Jun/16  Updated: 25/Jan/17  Resolved: 21/Jun/16

Status: Closed
Project: Core Server
Component/s: Replication
Affects Version/s: None
Fix Version/s: 3.3.9

Type: Task Priority: Major - P3
Reporter: Siyuan Zhou Assignee: Siyuan Zhou
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Depends
Related
is related to SERVER-24630 Mongos erroneously advances config op... Closed
is related to SERVER-26986 Drop all connections when transitioni... Closed
is related to SERVER-21456 Improve closing connection behavior w... Closed
Backwards Compatibility: Fully Compatible
Backport Requested:
v3.2
Sprint: Repl 16 (06/24/16)
Participants:
Linked BF Score: 0

 Description   

Currently, connections that are subjected to closing on stepdown are tagged in command::run(), this leaves the gaps before and after command::run() where closing could happen. Also, we have to consider retry if commands may hit the old primary during its stepping down.

Instead, this ticket suggests tagging all internal connections at the very beginning of establishing connections with an isMaster() call. We can add an extra field to isMaster to specify internal use so that servers may tag these connections KeepOpen.



 Comments   
Comment by Siyuan Zhou [ 29/Jul/16 ]

ramon.fernandez, after talking with milkie, we decided to postpone the backport because this ticket is a part of the primary catch-up project and it cannot be backported until we fix and backport SERVER-25126. The backport is trivial and has passed evergreen anyway.

Comment by Githook User [ 21/Jun/16 ]

Author:

{u'username': u'visualzhou', u'name': u'Siyuan Zhou', u'email': u'siyuan.zhou@mongodb.com'}

Message: SERVER-24574 Tag internal connections KeepOpen to avoid closing on stepdown
Branch: master
https://github.com/mongodb/mongo/commit/f922c515b54335a6b91ed0c10698f9a689bfb395

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