I've been able to reproduce this error. If you connect to the mysql server with MySQLdb, then restart the mysql server, and then attempt to use the MySQLdb connection object you just created, you'll get this error.
If you're running mod_python, this equates to accessing a page that uses MySQLdb, and then restarting mysql. After that, accessing a page that uses MySQLdb will give you this error. Restarting Apache will fix this.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am having this same problem, and I have found that restarting apache does indeed make the Interface errors disappear, but then after some time (hours) they come back.
I recently upgraded the machines I'm using to MySQLdb 1.2.0. I'm using an older version of mysql (3.23.58).
I can't get this error to happen on my development machine, but his could be that I don't often leave the web-server running there for long periods of time.
Does anyone think upgrading mysql could help with something like this? Any other ideas?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
InterfaceError is something that would be raised from deep inside _mysql. You should put in a bug for this issue; include steps to reproduce it with the latest test release.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Problem is I haven't been able to reproduce it. It seem to be happening sometimes when I haven't done anything for a while. A few times it happens when I'm going through pages.
I had a nagging suspicion about not using touples for the data part in the query
c.execute("SELECT %s", "test") instead of c.execute("SELECT %s", ("test",))
but I just got an error on a query that didn't have data at all. I'm really not sure, could be several bugs working together.
Using apache 2.0.52-3, mod_python 3.1.3-2.2, mysql 4.0.22, python 2.3.4-13 - running debian sarge.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If you are using a threaded Apache and/or mod_python, don't try to share the same connection object between threads. Bad things will happen. Read the thread in this forum about Apache and threads for how to do this properly.
I have no experience with mod_python or threaded Apache, so I can't offer much help beyond what is already in this forum.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Based on the page you referenced, and some additional poking around on the site, I believe mod_python uses threads even if Apache doesn't. None of the examples on that page are thread-safe and will crash. Use a connection pool.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
-n means 1000 connections, -c 9 means 9 concurrent connections, -v 3 makes everything the benchmark gets back printed on screen.
Except giving my server a nice 7 in load, nothing happend.
Python code for that page:
def showdata(req):
t=stuff.template("admin_units.tmpl", req)
t.tproc.set("Types",d.query("SELECT * FROM sys_unittype"))
t.tproc.set("Races",d.query("SELECT * FROM sys_races"))
t.tproc.set("Resources",d.query("SELECT * FROM sys_resources"))
t.tproc.set("Units",d.query("SELECT * FROM sys_units as db1, sys_races as db2, \
sys_unittype as db3 WHERE db1.race = db2.id AND db1.type = db3.id \
ORDER BY db1.race"))
return t.process()
This was with a newly started apache2. (cached files..)
I'll test a bit around and see if some pages fail more than other, and also try to see what's different in those pages.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am using MySQLDB for a web application, and I occasionally get these errors. I can't tell why they happen.
I am using version 1.16 of MySQLDB and v4.0.21 of Mysql.
The error is raised from MySQLdb/cursors.py on line 114. Presumably from line 102. But I can't tell what the actual problem is.
Has anyone seen this? can anyone tell me what might be the problem?
Thanks
Jonathan
I've been able to reproduce this error. If you connect to the mysql server with MySQLdb, then restart the mysql server, and then attempt to use the MySQLdb connection object you just created, you'll get this error.
If you're running mod_python, this equates to accessing a page that uses MySQLdb, and then restarting mysql. After that, accessing a page that uses MySQLdb will give you this error. Restarting Apache will fix this.
I am having this same problem, and I have found that restarting apache does indeed make the Interface errors disappear, but then after some time (hours) they come back.
I recently upgraded the machines I'm using to MySQLdb 1.2.0. I'm using an older version of mysql (3.23.58).
I can't get this error to happen on my development machine, but his could be that I don't often leave the web-server running there for long periods of time.
Does anyone think upgrading mysql could help with something like this? Any other ideas?
InterfaceError is something that would be raised from deep inside _mysql. You should put in a bug for this issue; include steps to reproduce it with the latest test release.
I'm having the same problems.
Problem is I haven't been able to reproduce it. It seem to be happening sometimes when I haven't done anything for a while. A few times it happens when I'm going through pages.
I had a nagging suspicion about not using touples for the data part in the query
c.execute("SELECT %s", "test") instead of c.execute("SELECT %s", ("test",))
but I just got an error on a query that didn't have data at all. I'm really not sure, could be several bugs working together.
Using apache 2.0.52-3, mod_python 3.1.3-2.2, mysql 4.0.22, python 2.3.4-13 - running debian sarge.
The select statements in your example don't do anything useful.
c.execute("SELECT %s", "test")
actually does: SELECT test
which is not even valid SQL.
c.execute("SELECT %s", ("test",))
actually does: SELECT 'test'
which simply returns a one-row, one-column result with the value 'test', i.e. c.fetchall() would return [('test',)].
About your mod_python version: 3.1.3-2.2 looks like version 3.1.3 compiled for Python-2.2; yet you are using Python-2.3.4.
And you failed to mention what version of MySQLdb (python-mysqldb on debian) you used.
didn't bother to write real queries, since that wasn't important in showing the difference
Just got the error on a page here:
Mod_python error: "PythonHandler mod_python.publisher"
Traceback (most recent call last):
File "/usr/lib/python2.3/site-packages/mod_python/apache.py", line 299, in HandlerDispatch
result = object(req)
File "/usr/lib/python2.3/site-packages/mod_python/publisher.py", line 136, in handler
result = util.apply_fs_data(object, req.form, req=req)
File "/usr/lib/python2.3/site-packages/mod_python/util.py", line 361, in apply_fs_data
return object(**args)
File "/home/dom2/web/html/code/admin.py", line 19, in showdata
t.tproc.set("Types",d.query("SELECT * FROM sys_unittype"))
File "/home/dom2/web/includes/database.py", line 40, in query
if data:
File "/usr/lib/python2.3/site-packages/MySQLdb/cursors.py", line 95, in execute
return self._execute(query, args)
File "/usr/lib/python2.3/site-packages/MySQLdb/cursors.py", line 114, in _execute
self.errorhandler(self, exc, value)
File "/usr/lib/python2.3/site-packages/MySQLdb/connections.py", line 33, in defaulterrorhandler
raise errorclass, errorvalue
InterfaceError: (0, '')
From query error log:
Error occured!
SQL Query : SELECT * FROM sys_unittype
SQL Data : None
Error : _mysql_exceptions.InterfaceError
Just logged in, and clicked on a link. So database had just been accessed before that.
If you are using a threaded Apache and/or mod_python, don't try to share the same connection object between threads. Bad things will happen. Read the thread in this forum about Apache and threads for how to do this properly.
I have no experience with mod_python or threaded Apache, so I can't offer much help beyond what is already in this forum.
I actually use the prefork MPM, which doesn't use threading.
The database wrapper is built on the code from
http://www.modpython.org/FAQ/faqw.py?req=show&file=faq03.003.htp
Based on the page you referenced, and some additional poking around on the site, I believe mod_python uses threads even if Apache doesn't. None of the examples on that page are thread-safe and will crash. Use a connection pool.
I don't think that's it either :-(
To test what you said, I ran a benchmark (ab2) against the heaviest page I got, and no errors.
Command: ab2 -n 1000 -c 9 -v 3 http://<url> | grep Error
-n means 1000 connections, -c 9 means 9 concurrent connections, -v 3 makes everything the benchmark gets back printed on screen.
Except giving my server a nice 7 in load, nothing happend.
Python code for that page:
def showdata(req):
t=stuff.template("admin_units.tmpl", req)
t.tproc.set("Types",d.query("SELECT * FROM sys_unittype"))
t.tproc.set("Races",d.query("SELECT * FROM sys_races"))
t.tproc.set("Resources",d.query("SELECT * FROM sys_resources"))
t.tproc.set("Units",d.query("SELECT * FROM sys_units as db1, sys_races as db2, \
sys_unittype as db3 WHERE db1.race = db2.id AND db1.type = db3.id \
ORDER BY db1.race"))
return t.process()
This was with a newly started apache2. (cached files..)
I'll test a bit around and see if some pages fail more than other, and also try to see what's different in those pages.