Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: What to do about OperationalErrors in Django
5 views
Skip to first unread message
Sheeri Cabral
Jan 29, 2013, 3:09:31 AM1/29/13
to Luke Crouch, Peter Bengtsson, Andy McKay, dev-w...@lists.mozilla.org, pet...@mozilla.com, Robert Helmer
+1 for 503 redirecting (sorry for the late reply, I was on vacation last week and am catching up!)
-Sheeri Cabral
Senior DB Admin/Architect
Mozilla
----- Original Message -----
From: "Luke Crouch" <lcr...@mozilla.com>
To: "Robert Helmer" <rhe...@rhelmer.org>
Cc: "Andy McKay" <amc...@mozilla.com>, "Peter Bengtsson" <pbeng...@mozilla.com>, dev-w...@lists.mozilla.org, pet...@mozilla.com, "Sheeri Cabral" <sca...@mozilla.com>
Sent: Tuesday, January 22, 2013 3:27:47 PM
Subject: Re: [webdev] What to do about OperationalErrors in Django
+1 503 w/ Retry-After !
-L
On 1/22/13 1:26 PM, Robert Helmer wrote:
On Tue, Jan 22, 2013 at 10:52 AM, Andy McKay < amc...@mozilla.com > wrote:
On 2013-01-22, at 10:47 AM, Luke Crouch < lcr...@mozilla.com > wrote:
>> Considering that these are almost always temporary errors that go away in between 1 to 100 seconds, should I perhaps write an error handler that catches any `OperationalError` and redirects to the same page it came from after a `time.sleep(1)`? I.e. instead of returning a 500 it returns a 302 after some delay.
You'd probably want to do this in the DatabaseConnector or something lower level, so that as far as the application is concerned - the SQL requests are just slow.
Don't go getting yourself into permanent waiting loop now :)
One concern I would have with this is that if nothing is returned to the user right away, they may try reloading excessively and kick off a ton of these (not to mention spiders etc)
Maybe return HTML immediately with an error page, but something like HTTP 503 + Retry-After, and an explanation like "The server is experiencing a temporary problem, retrying your query in n seconds..." ?
Then you are getting the client to do the polling, and you can suggest backoff by using Retry-After (I say "suggest " because in either scenario of course there's no control over what the client does, you can just minimize the resources you expend)
Not to say you shouldn't try to get to the bottom of the problem on the server side, or implement connection pooling or some kind of throttling mechanism (I don't think you'd need to roll this yourself)... anything that introduces a significant response delay and has a resource cost should be avoided if at possible though.
-Sheeri Cabral
Senior DB Admin/Architect
Mozilla
----- Original Message -----
From: "Luke Crouch" <lcr...@mozilla.com>
To: "Robert Helmer" <rhe...@rhelmer.org>
Cc: "Andy McKay" <amc...@mozilla.com>, "Peter Bengtsson" <pbeng...@mozilla.com>, dev-w...@lists.mozilla.org, pet...@mozilla.com, "Sheeri Cabral" <sca...@mozilla.com>
Sent: Tuesday, January 22, 2013 3:27:47 PM
Subject: Re: [webdev] What to do about OperationalErrors in Django
+1 503 w/ Retry-After !
-L
On 1/22/13 1:26 PM, Robert Helmer wrote:
On Tue, Jan 22, 2013 at 10:52 AM, Andy McKay < amc...@mozilla.com > wrote:
On 2013-01-22, at 10:47 AM, Luke Crouch < lcr...@mozilla.com > wrote:
>> Considering that these are almost always temporary errors that go away in between 1 to 100 seconds, should I perhaps write an error handler that catches any `OperationalError` and redirects to the same page it came from after a `time.sleep(1)`? I.e. instead of returning a 500 it returns a 302 after some delay.
You'd probably want to do this in the DatabaseConnector or something lower level, so that as far as the application is concerned - the SQL requests are just slow.
Don't go getting yourself into permanent waiting loop now :)
One concern I would have with this is that if nothing is returned to the user right away, they may try reloading excessively and kick off a ton of these (not to mention spiders etc)
Maybe return HTML immediately with an error page, but something like HTTP 503 + Retry-After, and an explanation like "The server is experiencing a temporary problem, retrying your query in n seconds..." ?
Then you are getting the client to do the polling, and you can suggest backoff by using Retry-After (I say "suggest " because in either scenario of course there's no control over what the client does, you can just minimize the resources you expend)
Not to say you shouldn't try to get to the bottom of the problem on the server side, or implement connection pooling or some kind of throttling mechanism (I don't think you'd need to roll this yourself)... anything that introduces a significant response delay and has a resource cost should be avoided if at possible though.
0 new messages