[sqlalchemy] Re: should a dns error return true in dialect.is_disconnect() ?
On Dec 4, 2007, at 3:26 PM, David Bonner wrote: Hi, I've run into a problem running SA 0.4.0 on top of psycopg2. We had a DNS hiccup, and the next attempt to execute a query triggered a ProgrammingError. Unfortunately, it seems that error didn't also invalidate the (implicit) connection, which was then returned to the pool. Successive queries returned a couple different errors (I can track down the exact sequence of errors if you need it) but eventually we end up getting InvalidRequestError(This connection is closed) every time we run a query. The backtrace looks something like: if the error message isnt caught by is_disconnect(), then yes the specific error message should be installed in there. But also note that psycopg2 has some specific issues with disconnects, namely that the exception is not always raised cleanly..i had discussed this on the psycopg2 list and supplied test scripts illustrating the issue but i dont know if anyone took the time to verify what i was illustrating. by not clean i mean the exception would get thrown in an asynchronous fashion so that we really couldnt catch it at all. ive seen tickets in psycopg2's trac which seem to address related issues. but also, that you were getting this connection is closed would indicate that a recycle did occur, although if you have pool logs that would describe it more clearly. But i wonder if you had long running Connection objects opened; at the moment, the Connection itself doesnt get a hold of a new DBAPI connection when a recycle occurs, youd have to open a new Connection. Ive been meaning to change this behavior in trunk so that even holding open Connection would still allow a new recycle to happen. Just curious how you configured on that end. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: should a dns error return true in dialect.is_disconnect() ?
On Dec 4, 4:32 pm, Michael Bayer [EMAIL PROTECTED] wrote: if the error message isnt caught by is_disconnect(), then yes the specific error message should be installed in there. But also note that psycopg2 has some specific issues with disconnects, namely that the exception is not always raised cleanly..i had discussed this on the psycopg2 list and supplied test scripts illustrating the issue but i dont know if anyone took the time to verify what i was illustrating. by not clean i mean the exception would get thrown in an asynchronous fashion so that we really couldnt catch it at all. ive seen tickets in psycopg2's trac which seem to address related issues. yeah, the more i think about it, the more i realize this is an error when the dbapi connection is created, it's not a disconnect condition. the original error message is No route to host, which I'm pretty sure is EHOSTUNREACH, which you get on a socket connect, not on a send. which means that yep, this is likely an async problem...the connection seems to be fine when you create it, but when you use it, it throws the connection error. but also, that you were getting this connection is closed would indicate that a recycle did occur, although if you have pool logs that would describe it more clearly. But i wonder if you had long running Connection objects opened; at the moment, the Connection itself doesnt get a hold of a new DBAPI connection when a recycle occurs, youd have to open a new Connection. Ive been meaning to change this behavior in trunk so that even holding open Connection would still allow a new recycle to happen. Just curious how you configured on that end. it's a long-running multi-threaded daemon process, using a TLEngine and all implicit connections. the lifespan of the sessions are pretty short, so i've assumed my threads weren't holding an open connection object. haven't configured pool logging to test it yet, though. suppose it's a good time to learn how to do that in 0.4 now. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: should a dns error return true in dialect.is_disconnect() ?
On Dec 4, 2007, at 5:39 PM, David Bonner wrote: yeah, the more i think about it, the more i realize this is an error when the dbapi connection is created, it's not a disconnect condition. the original error message is No route to host, which I'm pretty sure is EHOSTUNREACH, which you get on a socket connect, not on a send. which means that yep, this is likely an async problem...the connection seems to be fine when you create it, but when you use it, it throws the connection error. oh it was much weirder than that. we already do detect the disconnect on usage, so thats not an issue. the issue was literally: try: cursor.execute(some sql) except: detect_disconnect_and_invalidate() do_something() do_something_else() the cursor.execute would *not* raise an error. then, the program fails, and the stack trace would say: OperationalError: disconnect message at do_something_else() line 52 meaning, the stack trace originated from an *arbitrary spot* in the application ! you could actually control it like this: try: cursor.execute(some sql) time.sleep(5) except: detect_disconnect_and_invalidate() do_something() do_something_else() the time.sleep() would change the point of exception to be within the try/except block ! the ticket is here: http://www.initd.org/tracker/psycopg/ticket/183 and the second email in the thread has the test script. federico sort of thought it was a bug although i didnt follow his reasoning, but the ticket seems pretty dead. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: should a dns error return true in dialect.is_disconnect() ?
ah, seems to be OK using python 2.5 and psycopg2.0.6, so, i guess thats fixed somehow On Dec 4, 2007, at 5:59 PM, Michael Bayer wrote: On Dec 4, 2007, at 5:39 PM, David Bonner wrote: yeah, the more i think about it, the more i realize this is an error when the dbapi connection is created, it's not a disconnect condition. the original error message is No route to host, which I'm pretty sure is EHOSTUNREACH, which you get on a socket connect, not on a send. which means that yep, this is likely an async problem...the connection seems to be fine when you create it, but when you use it, it throws the connection error. oh it was much weirder than that. we already do detect the disconnect on usage, so thats not an issue. the issue was literally: try: cursor.execute(some sql) except: detect_disconnect_and_invalidate() do_something() do_something_else() the cursor.execute would *not* raise an error. then, the program fails, and the stack trace would say: OperationalError: disconnect message at do_something_else() line 52 meaning, the stack trace originated from an *arbitrary spot* in the application ! you could actually control it like this: try: cursor.execute(some sql) time.sleep(5) except: detect_disconnect_and_invalidate() do_something() do_something_else() the time.sleep() would change the point of exception to be within the try/except block ! the ticket is here: http://www.initd.org/tracker/psycopg/ticket/183 and the second email in the thread has the test script. federico sort of thought it was a bug although i didnt follow his reasoning, but the ticket seems pretty dead. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
