Menu

Interface error: (0,'')

Help
jon
2004-10-29
2012-09-19
  • jon

    jon - 2004-10-29

    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

     
    • Dylan Wolf

      Dylan Wolf - 2004-11-05

      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.

       
      • Tom McCarthy

        Tom McCarthy - 2005-05-29

        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?

         
    • Andy Dustman

      Andy Dustman - 2004-11-08

      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.

       
    • Mikael Turøy

      Mikael Turøy - 2004-12-07

      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.

       
      • Andy Dustman

        Andy Dustman - 2004-12-07

        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.

         
        • Mikael Turøy

          Mikael Turøy - 2004-12-07

          didn't bother to write real queries, since that wasn't important in showing the difference

           
    • Mikael Turøy

      Mikael Turøy - 2004-12-07

      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.

       
      • Andy Dustman

        Andy Dustman - 2004-12-07

        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.

         
        • Mikael Turøy

          Mikael Turøy - 2004-12-07

          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

           
          • Andy Dustman

            Andy Dustman - 2004-12-08

            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.

             
            • Mikael Turøy

              Mikael Turøy - 2004-12-10

              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.

               

Log in to post a comment.

Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.