Re: Database connection retry

Hi Jamesie. Two things stick out from the thread: Aymeric: might be more user-friendly, which is a goal. (If not too complex...) Tim: can you show us a patch to see what it would look like. Fancy putting together a POC? C. On Saturday, 15 December 2018 08:52:15 UTC+1, Jamesie Pic wrote: >

Re: Database connection retry

Nope, uwsgi in docker... -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com.

Re: Database connection retry

Are you using runserver in production ? On Sat, Dec 15, 2018, 08:52 Jamesie Pic Hi all, > > Sorry to bump this, but I didn't find another thread, and I'm pretty sure > re-trying the database connection is the sane thing to do. > > Otherwise, Django will remain in failed state after reboot in

Re: Database connection retry

Hi all, Sorry to bump this, but I didn't find another thread, and I'm pretty sure re-trying the database connection is the sane thing to do. Otherwise, Django will remain in failed state after reboot in some cases: psycopg2.OperationalError: FATAL: the database system is starting up It would

Re: Database connection retry

Thanks Aymeric! I'll give that a try next time! On Wednesday, March 8, 2017 at 3:20:31 PM UTC-6, Aymeric Augustin wrote: > > Hello, > > On 8 Mar 2017, at 21:23, Chris Foresman > wrote: > > I'll chime in to say I've had a similar problem related to the shell and I >

Re: Database connection retry

Hello, > On 8 Mar 2017, at 21:23, Chris Foresman wrote: > > I'll chime in to say I've had a similar problem related to the shell and I > couldn't sort out how to address it. In such situations, AFAIK, the following works: from django.db import connection

Re: Database connection retry

Chris, whilst I'm sure you could work something out, it probably wouldn't generally work as database connections contain a lot of state, such whether or not we're in a transaction and variables. On 8 March 2017 at 20:23, Chris Foresman wrote: > I'll chime in to say I've had

Re: Database connection retry

I'll chime in to say I've had a similar problem related to the shell and I couldn't sort out how to address it. Our database servers will drop connections that last longer than 10 minutes. So basically can never do a task I might otherwise use the shell for that would take longer than 10

Re: Database connection retry

It seems like we have 2 kind of issues: - code broke runserver, - network broke runserver. In the first case, runserver waits for a code reload event which is perfect ;) In the second case, runserver also waits for a code reload event, which is not very intuitive after fixing a network error.

Re: Database connection retry

Hello, > On 7 Mar 2017, at 13:30, James Pic wrote: > > My question is: is there anything we can do to automate this ? I'm not seeing an obvious solution to this problem. Django has no way to tell it's a temporary issue. -- Aymeric. -- You received this message because

Re: Database connection retry

It works on SyntaxErrors because updating the code triggers a reload, but if the check fails for something that's not related to code (db conn, redis conn...) then it's stuck and we have to manually interrupt runserver to start it again, unless we touch some code just to trigger the reload as you

Re: Database connection retry

The behavior of runserver hanging on a check error seems fine to me. That gives you an opportunity to fix the error without having to manually restart the server afterward -- just the same as if you had a SyntaxError. Am I missing the reason why the behavior is problematic? On Tuesday, March

Re: Database connection retry

Thanks for sharing some of your insight Aymeric, if I'm not mistaken then the auto-reload feature/case invalidates Shai's suggestion: would you recommend that the runserver process exits with non-zero when a check fails rather than being stuck waiting for another code change to trigger a reload,

Re: Database connection retry

> On 5 Mar 2017, at 12:27, James Pic wrote: > > However, I'm still a bit puzzled by having a process that's just stuck when > checks fail (if I understand correctly) is there any particular reason why it > is this way ? If not, perhaps a retry or exit could improve the

Re: Database connection retry

until manage check; do sleep 1; done; manage runserver would work for me then, thanks Shai ! However, I'm still a bit puzzled by having a process that's just stuck when checks fail (if I understand correctly) is there any particular reason why it is this way ? If not, perhaps a retry or exit

Re: Database connection retry

On Sunday 05 March 2017 12:32:34 James Pic wrote: > > However, perhaps runserver could just exit if checks don't pass, which > makes sense I think, allowing the optional use of a shell loop. I'd prefer > that, what do you think is better, exit or retry ? ... then you can do that yourself already

Re: Database connection retry

Thanks for your feedback, the use case i was talking about is not quite valid anymore, since docker-stack and docker-compose v3 ​do handle dependencies. However, perhaps runserver could just exit if checks don't pass, which makes sense I think, allowing the optional use of a shell loop. I'd

Re: Database connection retry

I don't know. Can you propose a patch so we can see what's involved? How would a "production" web server (nginx, apache, etc.) handle the issue? I'm more interested in moving runserver toward using gunicorn [0] (Windows support seems the main blocker to proceeding there) than adding more

Re: Database connection retry

Sometimes it's not started because some modern orchestration tools such as ansible-container and docker-compose (perhaps more) start everything at once, and django might be faster than the db, or I have to fix something with the db orchestration tool. I noted we might have the same issue with

Re: Database connection retry

Could you explain the use case a bit more? Why is your database failing on a regular basis? On Wednesday, March 1, 2017 at 4:00:12 PM UTC-5, James Pic wrote: > > Hi all, > > It seems like runserver won't retry to connect to the database after a > failing connection. Once the db server is up, it