[GODRIVER-285] Client should have a Close method Created: 19/Mar/18  Updated: 19/Apr/18  Resolved: 19/Apr/18

Status: Closed
Project: Go Driver
Component/s: CRUD
Affects Version/s: 0.0.2
Fix Version/s: 0.0.3

Type: New Feature Priority: Major - P3
Reporter: Kristofer Brandow (Inactive) Assignee: Kristofer Brandow (Inactive)
Resolution: Done Votes: 0
Labels: Stitch
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Duplicate
is duplicated by GODRIVER-284 Client should have a Close method Closed
Epic Link: GODRIVER Alpha UX

 Description   

The Client type should have a Close method so that users can shutdown the associated connections to a MongoDB deployment.

When this method returns, all sockets to the database from the Client instance must be closed.



 Comments   
Comment by Githook User [ 19/Apr/18 ]

Author:

{'email': 'kris@mongodb.com', 'username': 'skriptble', 'name': 'Kris Brandow'}

Message: Add Connect and Disconnect functionality

GODRIVER-285

Change-Id: I1d2eae1cc94a93c0664665541b12682131a49018
Branch: master
https://github.com/mongodb/mongo-go-driver/commit/94ae2dc59114fbf6dd39707929068adfa20a92e8

Comment by Kristofer Brandow (Inactive) [ 18/Apr/18 ]

Code Review: https://review.gerrithub.io/c/408109/.

Comment by Kristofer Brandow (Inactive) [ 04/Apr/18 ]

I spoke with eric.daniels and a few other people and here are my thoughts on how to move forward.

The main requirement is that after a Client has been "closed" there should be no more network traffic to the servers associated with that Client. This adds a couple of requirements to the implementation:

  1. The close method should take a context, so that it can timeout or be canceled if there is a long running command that a user would like to kill via another method.
  2. The close method should take a maxWait parameter. If this parameter is a positive duration, the close method will aggressively close all of the connections associated with the Client, including those that may have inflight read or write requests.

Together these two requirements allow for the use cases of close-and-wait, close-or-timeout, and close-or-aggressively-disconnect. Given that an io.Closer does not take a context nor a maxWait parameter and that in Go one should avoid naming methods that are interface methods if they have a different signature, we should call this close method Disconnect.

Additionally, to avoid memory churn in applications that create a large number of clients, calling Disconnect shouldn't irreversibly close either the Client nor the Topology. We should add another method, Connect, that will start monitoring goroutines and initialize the Client and Topology. The Topology type already has an initialization method that can be renamed to Connect, however Client currently auto connects. This goes against the principle of "constructors shouldn't have side effects".

We can either 1) Not change NewClient and add a new function NewUnconnectedClient that returns a client without calling Connect or 2) Change NewClient to not call Connect and add a new function NewConnectedClient that calls Connect.

Additionally, we might want to eventually explore being able to reset a Server so that we can reuse and pool those types as well.

Generated at Thu Feb 08 08:33:54 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.