Bug #68692 Workbench model synchronization timeout too short/non-configurable
Submitted: 16 Mar 2013 16:35 Modified: 21 Jul 2013 13:44
Reporter: James R Email Updates:
Status: No Feedback Impact on me:
None 
Category:MySQL Workbench: Administration Severity:S3 (Non-critical)
Version:5.2.47 OS:Microsoft Windows
Assigned to: CPU Architecture:Any
Tags: model, synchronize, timeout, workbench

[16 Mar 2013 16:35] James R
Description:
When making changes to models and then synchronizing, if tables are large the operations can be expected to take longer than the current timeout setting (600 seconds?).

Other posts indicate this is an issue for them and that the value is hard coded. None of the "Timeout Settings" under the "Options File" "Networking" tab seem to be related to this - the values are all far too high or low.

This is entirely reproducable and means that the synchronization wizard essentially cannot be used to perform lengthy operations. This isn't fatal because you can take the SQL generated, paste it into the SQL editor tab, and it works fine.

The error seen is:

Executing SQL script in server
ERROR: Error 2013: Lost connection to MySQL server during query

How to repeat:
Create a large table of data (e.g., > 100,000,000 rows, the columns need not be large). Try to do much of anything to it -- add a column, add an fk constraint... it ends up timing out.

Suggested fix:
Increase the timeout a lot (at least an hour, if not several hours), or make it configurable, or make it inherit one of the current settings such as wait_timeout.
[4 Apr 2013 14:42] Armando Lopez Valencia
Thanks a lot for your report.
[4 Apr 2013 15:42] James R
By the way though, due to the fact that you can't use Workbench for anything else while a query is running if you do it through the wizard, you are far better off on long queries copying the generated SQL and pasting it into a standard query tab. When done this way, you can continue to use the rest of the program, including running other queries in separate connections.

Given this, while it would be nice to not wait 10 minutes and then find out the query is going to fail, I can't recommend using the wizard for long queries anyway. Perhaps the easiest and most effective fix here is just a notice that this will happen so that users know to work around it.
[21 Jun 2013 5:15] Alfredo Kojima
If you have that many rows in a standards inserts tab for a table in modeling, there's probably something wrong with your modeling. Standard inserts are not meant to contain table dumps, it's just for initializing pre-defined constant data.
[21 Jun 2013 13:44] Alfredo Kojima
Hi, please provide detailed instructions about how to repeat. Your report doesn't make much sense, as it is filed under administration, but it seems to be about Modeling. You mention synchronization, but Inserts data isn't included in Synchronization. Thanks.
[22 Jul 2013 1:00] Bugs System
No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".