--- 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
> away').
> >> Restarting the webkit AppServer eliminates the immediate problem.
> >>
> >> I have not seen this problem on a lightly loaded server with
> Fedora
> >> Core 4, MySQL 4.1, and Webware 9.1. The Webkit AppServer is
> restarted
> >> by cron daily in both cases. In both cases the result of a call
> to
> >> Middlekit MySQLObjectStore is saved in the Sitepage module at load
> time
> >> for use by all servlets.
> >>
> >> Where should I be setting a timeout parameter for the Middlekit-
> MySql
> >> connection? Is 24 hours an unreasonable time limit?
> >
> > Did your version of MySQLdb change as well? I've had problems on
> more
> > than one occasion when upgrading.
> >
> > Also, is there a setting on the server side, perhaps? Maybe
> something
> > about how long to keep connections alive?
> >
> > If this ultimately requires a fix in MiddleKit, I'm not yet sure
> what
> > 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
> and
> > do some kind of recovery and retry. If you need help coding that,
> let
> > me know.
> >
> > But if there is a MySQL option that applies, that will be probably
> be
> > 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):
> Task.__init__(self)
> self.store = store
>
> def run(self):
> conn, cur = self.store.connectionAndCursor()
> try:
> conn.ping()
> except:
> pass
>
>
> 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.
>
> -Seth
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
clue:
'''
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
reconnection).
'''
Doing a:
/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
default.
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.
'''
[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
# Default to using old password format for compatibility with mysql 3.x
# clients (those using the mysqlclient10 compatibility package).
old_passwords=1
# rdh 2006-12-27 fix for OperationalError: (2006, 'MySQL server has
gone away')
wait_timeout=90000
[mysql.server]
user=mysql
basedir=/var/lib
[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
'''
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
[edit]
File "./WebKit/Application.py", line 540, in runTransaction [edit]
File "./WebKit/Application.py", line 564, in runTransactionViaServlet
[edit]
File "./WebKit/Servlet.py", line 59, in runTransaction [edit]
File "./WebKit/Transaction.py", line 136, in respond [edit]
File "./WebKit/HTTPServlet.py", line 67, in respond [edit]
File "Scripts/SitePage.py", line 309, in respondToGet [edit]
self._respond(transaction)
File "./WebKit/HTTPContent.py", line 105, in _respond [edit]
File "./WebKit/Page.py", line 30, in defaultAction [edit]
File "Scripts/Logon.py", line 52, in writeHTML [edit]
self.logonForm(message=0)
File "Scripts/Logon.py", line 89, in logonForm [edit]
self.spLogon(message=message,uName=uName)
File "Scripts/SitePage.py", line 426, in spLogon [edit]
users = sqldb.fetchObjectsOfClass('User',clauses='where
cookie="%s"' % cookieKey)
File "./MiddleKit/Run/SQLObjectStore.py", line 349, in
fetchObjectsOfClass [edit]
File "./MiddleKit/Run/SQLObjectStore.py", line 408, in executeSQL
[edit]
File "./MiddleKit/Run/MySQLObjectStore.py", line 56, in _executeSQL
[edit]
File "/usr/lib/python2.4/site-packages/MySQLdb/cursors.py", line 163,
in execute [edit]
self.errorhandler(self, exc, value)
File "/usr/lib/python2.4/site-packages/MySQLdb/connections.py", line
35, in defaulterrorhandler [edit]
raise errorclass, errorvalue
OperationalError: (2006, 'MySQL server has gone away')
Roger
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
|