We do not want to initSeed in Sum64.

// Sum64 returns h's current 64-bit value, which depends on
// h's seed and the sequence of bytes added to h since the
// last call to Reset or SetSeed.
//
// All bits of the Sum64 result are close to uniformly and
// independently distributed, so it can be safely reduced
// by using bit masking, shifting, or modular arithmetic.
func (h *Hash) Sum64() uint64 {
	h.initSeed()
	return rthash(h.buf[:h.n], h.state.s)
}

Ref https://jira.mongodb.org/browse/GODRIVER-1884 Ref https://jira.mongodb.org/browse/GODRIVER-1883 Ref https://jira.mongodb.org/browse/GODRIVER-1833

Hi 策 高, thank you for the report!

That sounds like expected behavior. A fixed number of connections are created per server for monitoring. This is in addition to >the connections created for application use (which is dictated by MinPoolSize and MaxPoolSize).

For Go driver 1.4.0+ there are a fixed 2 monitoring connections per server. For Go driver < 1.4.0 there is a fixed 1 monitoring connection per server.

When initializing the client with default configs, there is more than 1 connection (sometimes 2, sometimes 3) to the specific server.

If no MaxPoolSize was specified, the default MaxPoolSize is 100. And application connections are created as needed. The higher >rate of concurrent operations, the more application connections will be created, capping at MaxPoolSize.

When I set the MaxPoolSize to 2 and MinPoolSize to 2, I got 4 connections which are also unexpected.

If you are connecting to one server, since there are two monitoring connections, that is expected.

Sincerely, Kevin