[Twisted-Python] Consensus on how to handle "MySQL server has gone away"

[gelin yan]

On Wed, Oct 3, 2012 at 4:28 PM, Phil Mayers <p.mayers at imperial.ac.uk> wrote:

> On 10/02/2012 06:09 PM, E S wrote:
> > I have a service running that occasionally connects to a MySQL
> > database. When there is no activity on it for some time, I eventually
> > get the the error
> >
> > _mysql_exceptions.OperationalError: (2006, 'MySQL server has gone away')
> >
> > I have found a few posts on this group related to this issue
> >
> > http://twistedmatrix.com/pipermail/twisted-python/2007-July/015788.html
> >
> http://twistedmatrix.com/pipermail/twisted-python/2007-October/016178.html
> >
> > as well as some tickets on the twisted homepage:
> >
> > http://twistedmatrix.com/trac/ticket/4404
> > http://twistedmatrix.com/trac/ticket/4964
> >
> > I have also seen this referenced as a potential fix:
> >
> > http://www.gelens.org/2009/09/13/twisted-connectionpool-revisited/
> >
> > I currently have the cp_reconnect parameter set to True, but it does
> > not appear to be doing the job. I don't really see much consensus on
> > how to properly handle this issue. Some people seem to think that the
> > cp_reconnect parameter should take care of it for you, other people
> > say that cp_reconnect is only part of the solution and that you have
> > to write your own error handling.
>
> For what it's worth - I think adbapi is seriously sub-optimal in this
> regard. We have continual low-level problems with Twisted apps getting
> stuck due to hung/dead ConnectionPool. And if you forget cp_reconnect,
> well you are basically committing suicide. Your Twisted app will need a
> restart.
>
> In particular - it's not clear to my why CP isn't using "cp_good_sql" to
> probe a connection *before* starting the transaction, and to
> close/re-open it transparently if it has died and cp_reconnect==1.
>
> Instead, the only place the "good" SQL is run is *after* a rollback, so
> the next N transactions into the pool (where N is the number of threads)
> all fail, because they don't get as far as "rollback".
>
> I think the behaviour it should be aiming for is clear:
>
>   1. Test each connection with "good_sql" before beginning the user
> interaction/query
>   2. If execeptions occur inside the user interaction, either at cursor
> methods like execute, or connection methods like commit, then:
>      1. rollback - if *this* raises an exception, throw the conn away
>      2. propagate the original exception upwards unchanged (maybe
> wrapped, maybe not)
>
> cp_reconnect should be the default.
>
> _______________________________________________
> Twisted-Python mailing list
> Twisted-Python at twistedmatrix.com
> http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
>

Hi

  MySQLdb (If you use it) has its own socket wrappers and callings so the
only way to co-operate with twisted is to use adbapi. It is possible to use
other implementations but there are no one claim production ready.

Regards

gelin yan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://twistedmatrix.com/pipermail/twisted-python/attachments/20121003/b1b7b6f1/attachment.htm