one of our login forms had an error on it. we log python exceptions to sql
in a tween (pretty much using the same logic as in pyramid_exclog) under
pyramid 1.8.3
here's the edge case:
the broken form got hit by a botnet, and the nonstop errors ate up all the
space on the dedicated postgreql server logging device. the sqlalchemy
connection was erroneously not setup for autocommit, and that wedged the
underlying db connection into a broken transaction that never cleaned up.
so even after space was restored on that device, all exception logging was
broken because the finished callback never fired.
the tween logic was pretty much something like this:
try:
return handler(request)
except Exception as e:
# record e to db
raise
somehow, a stale database connection was created within the Exception block
and never released.
i've tried for hours, but I can't seem to create a use case situation where
I can break a connection in the `try` or `except` blocks, and it doesn't
get cleaned up by the finished callback under 1.8.3 or 1.9.x.
does anyone know what might cause a finished callback to *not* execute?
i've mostly fixed this by moving to an autocommit, but i'd like to figure
out what the heck happened.
--
You received this message because you are subscribed to the Google Groups
"pylons-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to pylons-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/pylons-discuss/0ac394f7-5c7f-4e00-a5b9-7fc50baed6d8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
