--- Seth Remington <sremington@...> wrote:
> chuck.esterbrook@... wrote:
> > On 12/26/06, Roger Haase <crosseyedpenguin@...> wrote:
> >> Hi,
> >> I am testing a new server with Fedora Core 6 and Middlekit-
> Webware 9.2
> >> and MySQL 5.0. When the new server is idle for 5 (or more) hours
> I get
> >> abends with OperationalError: (2006, 'MySQL server has gone
> >> Restarting the webkit AppServer eliminates the immediate problem.
> >> I have not seen this problem on a lightly loaded server with
> >> Core 4, MySQL 4.1, and Webware 9.1. The Webkit AppServer is
> >> by cron daily in both cases. In both cases the result of a call
> >> Middlekit MySQLObjectStore is saved in the Sitepage module at load
> >> for use by all servlets.
> >> Where should I be setting a timeout parameter for the Middlekit-
> >> connection? Is 24 hours an unreasonable time limit?
> > Did your version of MySQLdb change as well? I've had problems on
> > than one occasion when upgrading.
> > Also, is there a setting on the server side, perhaps? Maybe
> > about how long to keep connections alive?
> > If this ultimately requires a fix in MiddleKit, I'm not yet sure
> > it should be or where it should go, as I haven't experienced this
> > problem myself (but have not yet run MySQL 5 for lengthy periods of
> > time). One option you might try is tweaking
> > MiddleKit\Run\MySQLObjectStore.py to trap that specific exception
> > do some kind of recovery and retry. If you need help coding that,
> > me know.
> > But if there is a MySQL option that applies, that will be probably
> > the most expedient fix.
> > Let us know how it goes,
> > - Chuck
> I ran into this same issue in SaberNet DCS
> (http://sabernetdcs.sourceforge.net/). I don't recall all of the
> details when I researched it at the time but I can tell you the
> solution I came up with. It involves using the ping() function in
> MySQLdb to keep the connection alive:
> from TaskKit.Task import Task
> from sndcs.Store import store
> import time
> class KeepSQLAlive(Task):
> def __init__(self):
> self.store = store
> def run(self):
> conn, cur = self.store.connectionAndCursor()
> This is implemented as a TaskKit task and by default runs every 30
> seconds (probably overkill). The "store" object is a singleton data
> store instance used by everything, probably similar to what you
> describe in your app. Hope that helps.
Yes, the MySQL-python module changed from 1.2.0 to 1.2.1.
In checking my logs more closely, the problem occurred after 8 hours,
not 5 hours.
I think the cause is related to MySQL 5.0 changes, perhaps this from
http://dev.mysql.com/doc/refman/5.0/en/upgrading-from-4-1.html is a
The reconnect flag in the MYSQL structure is set to 0 by
mysql_real_connect(). Only those client programs which did not
explicitly set this flag to 0 or 1 after mysql_real_connect()
experience a change. Having automatic reconnection enabled by default
was considered too dangerous (due to the fact that table locks,
temporary tables, user variables, and session variables are lost after
/usr/libexec/mysqld --help --verbose
command yields a "wait_timeout" value of 28800 or 8 hours on both the
MySQL 4.1 and 5.0 installations. There doesn't appear to be a
"reconnect" or "mysql_real_connect" parameter that can be set as a
As I am not presently using TaskKit, Seth's suggested fix seemed a bit
too much work. So my try 1 was to edit /etc/my.cnf to add a
"wait_timeout" value of 90,000 seconds (25 hours) and restart mysqld.
# Default to using old password format for compatibility with mysql 3.x
# clients (those using the mysqlclient10 compatibility package).
# rdh 2006-12-27 fix for OperationalError: (2006, 'MySQL server has
Hopefully, the above change will work for me because Webkit is
restarted every 24 hours. The root problem appears to lie between
MySQLdb and MySQL 5.0. For the record, here is the traceback.
Traceback (most recent call last):
File "./WebKit/Application.py", line 477, in dispatchRawRequest
File "./WebKit/Application.py", line 540, in runTransaction 
File "./WebKit/Application.py", line 564, in runTransactionViaServlet
File "./WebKit/Servlet.py", line 59, in runTransaction 
File "./WebKit/Transaction.py", line 136, in respond 
File "./WebKit/HTTPServlet.py", line 67, in respond 
File "Scripts/SitePage.py", line 309, in respondToGet 
File "./WebKit/HTTPContent.py", line 105, in _respond 
File "./WebKit/Page.py", line 30, in defaultAction 
File "Scripts/Logon.py", line 52, in writeHTML 
File "Scripts/Logon.py", line 89, in logonForm 
File "Scripts/SitePage.py", line 426, in spLogon 
users = sqldb.fetchObjectsOfClass('User',clauses='where
cookie="%s"' % cookieKey)
File "./MiddleKit/Run/SQLObjectStore.py", line 349, in
File "./MiddleKit/Run/SQLObjectStore.py", line 408, in executeSQL
File "./MiddleKit/Run/MySQLObjectStore.py", line 56, in _executeSQL
File "/usr/lib/python2.4/site-packages/MySQLdb/cursors.py", line 163,
in execute 
self.errorhandler(self, exc, value)
File "/usr/lib/python2.4/site-packages/MySQLdb/connections.py", line
35, in defaulterrorhandler 
raise errorclass, errorvalue
OperationalError: (2006, 'MySQL server has gone away')
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around