[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: |
|
||||||||||||
| 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 Change-Id: I1d2eae1cc94a93c0664665541b12682131a49018 |
| 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:
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. |