Bug #80188 | DBMS connection read time out (in seconds) is not disabled when set to 0 | ||
---|---|---|---|
Submitted: | 28 Jan 2016 14:45 | Modified: | 14 Jun 2018 19:16 |
Reporter: | Joe Grasse (OCA) | Email Updates: | |
Status: | Closed | Impact on me: | |
Category: | MySQL Workbench: SQL Editor | Severity: | S3 (Non-critical) |
Version: | 6.3.6 | OS: | Any |
Assigned to: | CPU Architecture: | Any |
[28 Jan 2016 14:45]
Joe Grasse
[28 Jan 2016 15:30]
Peter Laursen
I think you should understand the documentation like when set to "0" in WB will not set a SESSION value and the server GLOBAl value will have effect for the connecton. What does "SHOW VARIABLES LIKE 'wait_timeout';" return on this server? 300? If I am right, docs should definitely be more clear and also I think it should use/refer the real name of the variable ("wait_timeout" - http://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html#sysvar_wait_timeout) governing timeout for a succesfully established connection. -- Peter -- not an Oracle/MySQL person
[28 Jan 2016 15:57]
Joe Grasse
No wait_timeout and interactive_timeout are set to 899.
[28 Jan 2016 15:59]
Joe Grasse
Also, those settings apply to connections that are idle. The problem I am talking about is when a query is running.
[28 Jan 2016 18:36]
MySQL Verification Team
Verified - setting read timeout to 0 in Workbench still results in a lost connection when sleeping for > 10 minutes.
[24 May 2018 16:51]
Miguel Tadeu Mota
Posted by developer: commit id: fdd0c3734650f6ebe377a6ddca8470f59746ac2b
[14 Jun 2018 19:16]
Christine Cole
Posted by developer: Fixed as of the upcoming MySQL Workbench 8.0.12 release, and here's the changelog entry: An active connection to MySQL server was closed unexpectedly with the DBMS connection read time out (in seconds) preference option set to zero, which should keep the connection open. Thank you for the bug report.