Warning: Can't synchronize with repository "(default)" (Unsupported version control system "svn": No module named svn). Look in the Trac log for more information.

Ticket #872 (closed defect: fixed)

Opened 13 years ago

Last modified 9 years ago

MySQLdb/gears does not reconnect if mysql drops connection

Reported by: eastham@… Owned by: anonymous
Priority: high Milestone: 1.5
Component: SQLObject Version: 1.0.1
Severity: major Keywords: mysql, SO , SA
Cc:

Description

At present, TG is permanently hosed if you lose the mysql connection. This can happen if the connection times out, or the server is restarted. This is not going to fly in a production environment, or in one where your hosting provider does dumb things to the database settings.

On Mark Ramm's request, I am filing this ticket so that once MySQLdb exposes an auto-reconnect interface, SQLObject/Gears can make use of it.

I have submitted a patch to the MySQLdb sourceforge that exposes the interface. Hopefully they will add it soon. Link:http://sourceforge.net/tracker/index.php?func=detail&aid=1483074&group_id=22307&atid=374934

Here's a thread on this topic, which includes a quicker hardcoded workaround (also in the MySQLdb code -- I couldn't find any other way to do it):

 http://groups.google.com/group/turbogears/browse_frm/thread/4f0ae451e72b4717/7cfd7592010b4959?lnk=arm#7cfd7592010b4959

Change History

comment:1 Changed 13 years ago by jvanasco@…

Just to add - postgres exhibits a similar problem ( at least with sessions ) -- but seems to reconnect after an invalid request

A workaround I found that seems to be working, is to use tg scheduler as such:

import psycopg2 
def get_db_for_sessions():
    dsn = get('sessions.postgres.dsn')
    return psycopg2.connect(dsn) 

def _session_db_ping():
    print "_session_db_ping"
    x= get_db_for_sessions()
   
add_interval_task( action=_session_db_ping, taskname='_session_db_ping', initialdelay=0, interval=270 )

that pings the db by calling a connect every 4.5 minutes -- it would probably work with mysql

comment:2 Changed 13 years ago by jorge.vargas

I have move this to the SO bug tracker ticket 1547004, http://tinyurl.com/nqqyv if you have new information on this please post it there.

I'm not closing this bug until that one is closed.

comment:3 Changed 13 years ago by jorge.vargas

  • Milestone changed from 0.9 to 1.0

comment:4 Changed 13 years ago by stickystyle

The same issue exists in SA, it is referenced in this ticket  http://www.sqlalchemy.org/trac/ticket/121

comment:5 Changed 12 years ago by alberto

  • Milestone changed from 1.0 to 1.1

comment:6 Changed 12 years ago by jorge.vargas

I have talk to Oleg about this several times someone track it to the driver code and I believe in the latest release it should work.

as for the SA code it seems to be commited based on the ticket.

in both cases please test and report back here.

comment:7 Changed 12 years ago by alberto

  • Milestone changed from 1.1 to __unclassified__

Batch moved into unclassified from 1.1 to properly track progress on the later

comment:8 Changed 12 years ago by anseljh

  • Keywords mysql added
  • Version changed from 0.9a5 to 1.0.1
  • Milestone changed from __unclassified__ to 1.0.2

Hello... I just ran into this bug and, between the two bugs on this Trac, bugs on other trackers, and multiple mailing list threads, I'm rather confused on the current status. I would really appreciate it if someone could post an "executive summary" of this bug's status. If it's fixed, exactly which package(s) fix it? I think this would be helpful for other people too and perhaps worthy of a TG wiki page. It should also be a priority to make sure the next TG release includes/requires the fixed package(s).

As for me, I get a 500 error with a "MySQL server has gone away" exception in the morning if I leave my TG app running overnight. This is obviously not going to fly; it's a blocker. :(

I'm running this on Fedora Core 6's stock TurboGears 1.0.1 yum/RPM packages:

  • TG 1.0.1
  • MySQLdb 1.2.1
  • SQLObject 0.7.2
  • MySQL 5.0.27

Thanks a lot!

P.S. I'm changing the version for this bug from 0.9a5 to 1.0.1 since I confirmed it with 1.0.1. I'm also changing the milestone from unclassified to 1.0.2. Feel free to change as appropriate, but I think those make sense.

comment:9 Changed 12 years ago by alberto

  • Milestone changed from 1.0.2 to 1.0.3

comment:10 Changed 12 years ago by faide

  • Milestone changed from 1.0.3 to 1.1

comment:11 Changed 11 years ago by Chris Arndt

Both the SQLObject and the SQLAlchemy bugs referenced above are now closed. The closing message to the SQLObject bug indicates that you need MySQLdb 1.2.2+ and MySQL 5.0.x. Anyway, this is not really a TurboGears bug, is it? Should we close this?

comment:12 Changed 11 years ago by anseljh

My sense is that this bug (no matter what the source) has been enough of a showstopper that TG should provide a workaround if the underlying bugs are in other packages. Therefore, I propose not closing this until either (a) we have a verified fix in the underlying packages, or (b) provided a good workaround.

I'll make sure I have the latest packages, will disable the workaround I've been using, and will post the results back here (hopefully tonight?).

comment:13 Changed 11 years ago by Chris Arndt

Good, sounds like a plan! But make sure you don't keep the db connection alive by testing it periodically ;-)

Take your time, this ticket has been open for so long, another few days won't hurt.

comment:14 Changed 11 years ago by faide

  • Keywords mysql, SO , SA added; mysql removed
  • Status changed from new to closed
  • Resolution set to fixed

Using the latest packages for mysqldb SO or SA should now handle this situation cleanly... closing this bug for the moment.

Please reopen only if latest packages do expose this bug again...

Note: See TracTickets for help on using tickets.