go: database/sql: DB full resetterCh causes driver.ErrBadConn error
What version of Go are you using (go version
)?
$ go version go version go1.12 linux/amd64
Does this issue reproduce with the latest release?
yes
What operating system and processor architecture are you using (go env
)?
go env
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
$ go env
What did you do?
I am doing stress test for mysql server using golang. I create a sql.DB and set
db.SetMaxOpenConns(128)
db.SetMaxIdleConns(32)
Then I create 500 go-routines (500 clients) and send 1000000 queries to mysql server.
After I run the program, it sometimes pops up error “driver: bad connection” (driver.ErrBadConn
).
I found that in sql.OpenDB, it creates a *sql.DB struct with: resetterCh: make(chan *driverConn, 50)
In func (db *DB) putConn(dc *driverConn, err error, resetSession bool)
, if db.resetterCh
is full, it marks connection as bad
select {
default:
// If the resetterCh is blocking then mark the connection
// as bad and continue on.
dc.lastErr = driver.ErrBadConn
dc.Unlock()
case db.resetterCh <- dc:
}
and if number of connections exceeds max connection, it reuses old connection which is marked as bad and return driver.ErrBadConn
.
I can solve it by set max connection less than 50 (which is size of db.resetterCh
).
Why did you hardcoded size of db.resetterCh
to 50?
Should it be set to max connections?
https://play.golang.org/p/phUILuRV3hJ
What did you expect to see?
What did you see instead?
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Reactions: 9
- Comments: 17 (7 by maintainers)
Commits related to this issue
- [release-branch.go1.13] database/sql: backport 5 Tx rollback related CLs Manually backported the subject CLs, because of lack of Gerrit "forge-author" permissions, but also because the prior cherry p... — committed to golang/go by odeke-em 4 years ago
- [release-branch.go1.14] database/sql: backport 5 Tx rollback related CLs Manually backported the subject CLs, because of lack of Gerrit "forge-author" permissions, but also because the prior cherry p... — committed to golang/go by odeke-em 4 years ago
I can see two solutions to this issue:
I’ll look into this more. I’m not ready for a final fix (the referenced CL isn’t quite right I think). If someone wants to submit a CL in the next couple of days that would be great. We are really close to the 1.13 freeze.