[SERVER-5587] Command to close current connections Created: 12/Apr/12  Updated: 08/Apr/19  Resolved: 08/Apr/19

Status: Closed
Project: Core Server
Component/s: Networking, Testing Infrastructure
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Minor - P4
Reporter: A. Jesse Jiryu Davis Assignee: A. Jesse Jiryu Davis
Resolution: Done Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Related
related to SERVER-5632 Add a way to flush all connections in... Closed
is related to SERVER-34551 Add failpoint to fail commands with n... Closed
Sprint: Service Arch 2019-04-08, Service Arch 2019-04-22
Participants:

 Description   

For driver testing, it'd be great to have a server command that closed all current connections (similar to how a primary acts when it steps down). See PYTHON-345 for example of a driver bug that's hard to test without a 'closeConnections' command.



 Comments   
Comment by A. Jesse Jiryu Davis [ 08/Apr/19 ]

jmikola says, "I agree with closing as "gone away". Neither Oleg's recent spec tests for "cursors survive primary step down" nor Sam's work on the failover testing spec need this in light of other available tools."

Comment by A. Jesse Jiryu Davis [ 08/Apr/19 ]

I think that in the nearly 7 years that have passed since I opened it, this ticket has grown obsolete:

1. We now have the very powerful failCommand failpoint (SERVER-34551), which can hang up on specific commands (in addition to many other configurations)
2. Starting in 4.2, primaries no longer close connections on stepdown, so the importance of testing this scenario will fade

I've asked the Drivers leads to confirm.

Comment by Daniel Gottlieb (Inactive) [ 12/Apr/12 ]

It'd also be nice if, for testing replica set connections, we could simulate latency at the socket level as well. Though I personally wouldn't mind using a mongobridge for each connection, in the sense that it might be messy to ensure that the command that modifies latency doesn't actually incur the configured latency penalty.

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