Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

database/sql: improve recovery from server timeouts #8834

Closed
gopherbot opened this issue Sep 29, 2014 · 8 comments
Closed

database/sql: improve recovery from server timeouts #8834

gopherbot opened this issue Sep 29, 2014 · 8 comments
Milestone

Comments

@gopherbot
Copy link

@gopherbot gopherbot commented Sep 29, 2014

by arnehormann:

database/sql attempts to issue queries 10 times (value of maxBadConnRetries) until it
succeeds.

When all connections are idle for longer than some server timeout, the network
connections in the whole connection pool may have been closed by the server.
If 10 database connections are tried and all have been closed by the server, the query
will return an error.

Recovery is still possible by recreating the connections, but the number of retries
should be larger than the pool size (e.g. 1 + db.maxOpen).
@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Sep 29, 2014

Comment 1:

Labels changed: added repo-main, release-go1.5.

@gopherbot
Copy link
Author

@gopherbot gopherbot commented Oct 20, 2014

Comment 2 by lperjiao:

should the number of retries be 1+db.MaxIdle ?
@gopherbot
Copy link
Author

@gopherbot gopherbot commented Oct 20, 2014

Comment 3 by arnehormann:

Probably. And that's probably a lot better than db.maxOpen.
@gopherbot
Copy link
Author

@gopherbot gopherbot commented Nov 2, 2014

Comment 4 by marko@joh.to:

I've implemented what I think is a cleaner approach in
https://golang.org/cl/168060044.  It essentially makes maxBadConnRetries the
maximum number of bad connections to discard from the pool per query, and then forces an
attempt with a fresh connection after maxBadConnRetries.
@gopherbot
Copy link
Author

@gopherbot gopherbot commented Nov 2, 2014

Comment 5 by arnehormann:

Neat idea!
That probably also helps to integrate deadlines in database/sql (to support
code.google.com/p/go.net/context - as proposed in 
https://golang.org/issue/8874).
And I think maxBadConnRetries should be 1, then.
@xiezhenye
Copy link

@xiezhenye xiezhenye commented May 9, 2016

Why maxBadConnRetries is hard coded but not a configurable option? Sometimes I do not want it to retry when connect fails.

@johto
Copy link
Contributor

@johto johto commented May 10, 2016

Why maxBadConnRetries is hard coded but not a configurable option? Sometimes I do not want it to retry when connect fails.

maxBadConnRetries isn't really about connection attempts; I'd expect a driver not to return ErrBadConn on a failed connection attempt, because it hides the error message from the user. If the user does want to retry, he/she can do it in the call outside of database/sql. Further, setting maxBadConnRetries to 0 would mean that database/sql would stop cleaning up bad connections from the pool, which doesn't sound reasonable at all.

What's the actual use case here?

@xiezhenye
Copy link

@xiezhenye xiezhenye commented May 10, 2016

Reties may seldom success when first attempt fails, and the latency time will be longer (e.g. ReadTimeout * 3).

when maxBadConnRetrie set to 0, connection pool will actually be ignored, and maxIdleConn should also set to 0.

p.s.
recently, maxBadConnRetries can not be simply set to 0. I've write a patch to implement a method SetMaxBadConnRetries on *DB.

see https://golang.org/cl/22968

@golang golang locked and limited conversation to collaborators May 10, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants
You can’t perform that action at this time.