@JonB said in Qt Mysql [Mysql Server has gone away] and Silent failures after query exec():
@mvsri said in Qt Mysql [Mysql Server has gone away] and Silent failures after query exec():
like 10+ hours any statements like update or insert doesn't work.
This may be significant. From your INSERT example you are using prepare() and you are binding variables. Please read https://forum.qt.io/topic/107690/lost-connection-to-mysql-server-during-query-qmysql3-unable-to-reset-statement carefully. There the suggestion is that this may fail to reconnect even with the reconnection option. If your problem is reproducible can you, at least temporarily/as a test change to make the query a string with whatever in it and abandon preparation and variable substitution? Does that make the problem go away? Furthermore, you check the result of exec() but when you do use prepare() you do not check the result it returns. You should do so. That may reveal an error at that stage.
Also, given that abandonment of MYSQL_OPT_RECONNECT has either happened or is about to happen, you might remove this from your code and do whatever you have to manage reconnection yourself, to see whether that improves the situation.
I do not know why your other audit log connection appears to work while your main one fails. Even more complex is your "writes to MySQL via QtConcurrent::run". I was under the impression that Qt requires you to write to a SQL connection from the same thread as where it was created/currently lives, won't QtConcurrent::run() break precisely that rule? Yet that one works. Who knows?!
I have gone through this thread: https://forum.qt.io/topic/107690/lost-connection-to-mysql-server-during-query-qmysql3-unable-to-reset-statement/6.
In my case, I’ve been using QString to build the query and pass it to the functions in databaseconnector class and passing it to QSqlQuery.
To recreate the issue, I restarted the MySQL server from Services (windows), and I received the same error:
Lost connection to MySQL server during query QMYSQL: Unable to execute query" (:0, )
After this, I implemented reconnection logic that attempts to reconnect if QSqlQuery::exec() fails and give connection error. When I recreated the same scenario (restarting the MySQL server), the reconnection worked as expected.
Based on suggestions and further reading of the documentation, I’ve also modified my code to avoid holding the QSqlDatabase instance as a class variable and instead use it as a function-local variable.
Regarding the AuditLogger class, I’ve completely reimplemented it and now use QMetaObject::invokeMethod for logging operations.
While reviewing the documentation and googling for MYSQL_OPT_RECONNECT, it appears this option may no longer work as expected with recent versions. So, I’m considering removing it from the code.
One pending task is to check the MySQL server logs—I haven’t received them yet, but once I do, I’ll analyze them for further insight.
One doubt I have is:
The system where the application is running is part of a domain network, governed by Group IT policies, and has antivirus installed.
Could this environment be a potential cause for the dropped connection? (I understand this might be a naive question, but I’d like to rule out any possible cause.)
Thank you again for your inputs—they’ve helped clarify several concepts for me.
