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

packets: reset read deadline before conn check #964

Merged
merged 2 commits into from May 7, 2019

Conversation

vmg
Copy link
Contributor

@vmg vmg commented May 7, 2019

Hiii mysqlinos! Here's a fix for an issue that @lrita reported. Fixes #963.

cc @methane @julienschmidt

Description

If a MySQL connection has been configured with a short `ReadTimeout`,
each read from the TCP connection will be preceded by a
`SetReadDeadline` call, which lingers until the next `SetReadDeadline`.

This can be an issue if the connection becomes stale after staying too
long in the connection pool, because when we attempt to perform a stale
connection check, the Go runtime scheduler will return a timedout error
from the scheduler itself, without letting us get to the kernel to
perform the non-blocking read.

To fix this, reset the read deadline before we perform the connection
check.

Checklist

  • Code compiles correctly
  • Created tests which fail without the change (if possible)
  • All tests passing
  • Extended the README / documentation, if necessary
  • Added myself / the copyright holder to the AUTHORS file

If a MySQL connection has been configured with a short `ReadTimeout`,
each read from the TCP connection will be preceded by a
`SetReadDeadline` call, which lingers until the next `SetReadDeadline`.

This can be an issue if the connection becomes stale after staying too
long in the connection pool, because when we attempt to perform a stale
connection check, the Go runtime scheduler will return a timedout error
from the scheduler itself, without letting us get to the kernel to
perform the non-blocking read.

To fix this, reset the read deadline before we perform the connection
check.
packets.go Outdated
// reads, reset it to its default value before we attempt a non-blocking
// read, otherwise the scheduler will just time us out before we can read
if mc.cfg.ReadTimeout != 0 {
err = conn.SetReadDeadline(time.Now().Add(mc.cfg.ReadTimeout))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should use 0 here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

@julienschmidt julienschmidt merged commit 8056f2c into go-sql-driver:master May 7, 2019
@julienschmidt julienschmidt added this to the v1.5.0 milestone May 7, 2019
tz70s pushed a commit to tz70s/mysql that referenced this pull request Sep 5, 2020
* packets: reset read deadline before conn check

If a MySQL connection has been configured with a short `ReadTimeout`,
each read from the TCP connection will be preceded by a
`SetReadDeadline` call, which lingers until the next `SetReadDeadline`.

This can be an issue if the connection becomes stale after staying too
long in the connection pool, because when we attempt to perform a stale
connection check, the Go runtime scheduler will return a timedout error
from the scheduler itself, without letting us get to the kernel to
perform the non-blocking read.

To fix this, reset the read deadline before we perform the connection
check.

* packets: set a 0 deadline
tz70s pushed a commit to tz70s/mysql that referenced this pull request Sep 5, 2020
* packets: reset read deadline before conn check

If a MySQL connection has been configured with a short `ReadTimeout`,
each read from the TCP connection will be preceded by a
`SetReadDeadline` call, which lingers until the next `SetReadDeadline`.

This can be an issue if the connection becomes stale after staying too
long in the connection pool, because when we attempt to perform a stale
connection check, the Go runtime scheduler will return a timedout error
from the scheduler itself, without letting us get to the kernel to
perform the non-blocking read.

To fix this, reset the read deadline before we perform the connection
check.

* packets: set a 0 deadline
@zjj zjj mentioned this pull request Jan 8, 2022
5 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

false positive in checking connection liveness
3 participants