Hello, Josh.
On Nov 17, 4:34 am, Josh Kelley <josh...@gmail.com> wrote:
> On Nov 16, 5:45 pm, Gustavo Narea <m...@gustavonarea.net> wrote:
>
> > Thanks for the information.
>
> > I couldn't find the message "Can't reconnect until invalid transaction
> > is rolled back" in the output you pasted and I think the link to the
> > FAQ refers to another type of issue.
>
> Sorry. There are actually two exceptions; the first I already posted,
> and here's the second, with the "Can't reconnect until invalid
> transaction is rolled back" error.
>
> http://pastie.org/1304673
>
> I don't know why I got two exceptions on a single request? I assumed
> the Pylons / repoze stack would have aborted after the first. (Unless
> the second exception was while trying to render the error page? If
> that is what's happening, is there a way to keep repoze.who from
> breaking rendering the error page?)
>
> > I've been reading about that error on the MySQL documentation and it
> > seems like all the possible causes are external to the
> > application:http://dev.mysql.com/doc/refman/5.0/en/gone-away.html
>
> > You can try and tweak the Session if you want; it may or may not help.
> > I don't think handling the exception in repoze.who.plugins.sa is an
> > appropriate solution because we'd silencing a problem that should be
> > fixed.
>
> I understand that the causes of the "MySQL server has gone away" are
> external to the app and will work on that later; my concern right now
> is that (as far as I can tell) repoze.who.plugins.sa isn't cleaning up
> when this happens, which causes the app to get stuck in the "Can't
> reconnect until invalid transaction is rolled back" state (and I have
> to restart the app to get anything working again). The FAQ I linked
> to does appear to be a different specific issue, but its solution of
> using a try/except block to properly handle rollbacks seems to apply
> here too.
If I make repoze.who.plugins.sa handle the exception, I'd be silencing
that error, which I'd rather not do as that sort of things always make
debugging harder.
If you had another WSGI middleware that uses SA, chances are you'd get
the same error, so I think a better solution for you would be to
subclass ErrorMiddleware like this:
"""
class MyErrorMiddleware(ErrorMiddleware):
def exception_handler(self, exc_info, environ):
exception_class = exc_info[0]
if exception_class in (InvalidRequestError, OperationalError):
# rollback...
return super(MyErrorMiddleware,
self).exception_handler(exc_info, environ)
"""
That should avoid the second exception, allowing the error page to be
returned without problems. And it'd also work if that error happens
within your application and you're not expecting it.
I'm happy to reconsider handling the exception if more hit the same
problem, though.
HTH,
- Gustavo.
--
You received this message because you are subscribed to the Google Groups
"pylons-discuss" group.
To post to this group, send email to pylons-disc...@googlegroups.com.
To unsubscribe from this group, send email to
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en.
