Re: prevent AppConfig.ready() from running twice
Thanks so much, y'all! Very helpful! On Sunday, June 24, 2018 at 3:47:48 AM UTC-4, Mike Dewhirst wrote: > > On 23/06/2018 6:17 PM, Melvyn Sopacua wrote: > > On zaterdag 23 juni 2018 02:01:06 CEST Mike Dewhirst wrote: > > > >> Is there a python singleton pattern which might work? > > No, cause the startup is done in 2 different processes which do not > share > > state. So both processes will have a "new singleton". > > This is why you need an IPC mechanism, such as file locks or shared > memory. > > OK. That's very clear. Thank you Melvyn. > > Cheers > > Mike > > > In > > the case of one-off launchers, it's usually easier to implement the > > restrictions on the client side (the program being launched). Long > running > > launchers (like inetd, systemd) can prevent double launch in other ways > as > > they can keep their own state. > > -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/5bee9c83-aec8-4a72-a9e6-1196bb989df1%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: prevent AppConfig.ready() from running twice
On 23/06/2018 6:17 PM, Melvyn Sopacua wrote: On zaterdag 23 juni 2018 02:01:06 CEST Mike Dewhirst wrote: Is there a python singleton pattern which might work? No, cause the startup is done in 2 different processes which do not share state. So both processes will have a "new singleton". This is why you need an IPC mechanism, such as file locks or shared memory. OK. That's very clear. Thank you Melvyn. Cheers Mike In the case of one-off launchers, it's usually easier to implement the restrictions on the client side (the program being launched). Long running launchers (like inetd, systemd) can prevent double launch in other ways as they can keep their own state. -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/968115a0-5e2a-c141-cf17-fa6de4a65583%40dewhirst.com.au. For more options, visit https://groups.google.com/d/optout.
Re: prevent AppConfig.ready() from running twice
On zaterdag 23 juni 2018 02:01:06 CEST Mike Dewhirst wrote: > Is there a python singleton pattern which might work? No, cause the startup is done in 2 different processes which do not share state. So both processes will have a "new singleton". This is why you need an IPC mechanism, such as file locks or shared memory. In the case of one-off launchers, it's usually easier to implement the restrictions on the client side (the program being launched). Long running launchers (like inetd, systemd) can prevent double launch in other ways as they can keep their own state. -- Melvyn Sopacua -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/3828451.OQlbSIQ3MC%40fritzbook. For more options, visit https://groups.google.com/d/optout.
Re: prevent AppConfig.ready() from running twice
Makes sense - thank you Eric M On 23/06/2018 5:10 PM, PASCUAL Eric wrote: IMHO, some of (a lot of ?) the "classical" GOF patterns do not really apply to Python (or at least are not necessary, when not making things more confuse). They are often a consequence of constraints and limitations of statically compiled languages such as C++, Java and alike used at the time they have been created, but they loose most of their interest for languages such as Python. If the singleton instance is used internally by your application code, and apart if you have really good reasons for making things more complicated, juts use a module level variable to store the instance, and initialize it at application start. Of course, forbid yourself to write to this variable from elsewhere than the app initialization code. If the singleton creation can be called from other places (f.i. if a lazy initialization strategy is used), and if there are possibilities for it to be called several times, a guard can be implemented by providing a factory function which will test if the instance is currently None, instantiate one if needed, store it in the module variable, and return the module variable at the end. It would look like this: _singleton_instance = None def get_singleton(): if _singleton_instanceis None: _singleton_instance= return _singleton_instance The '_' prefix of the singleton variable is use to indicate that this is a "private" variable which must not be referred to (even in read access) from outside the module. Hope this helps. Regards Eric *From:* django-users@googlegroups.com on behalf of Mike Dewhirst *Sent:* Saturday, June 23, 2018 2:01:06 AM *To:* django-users@googlegroups.com *Subject:* Re: prevent AppConfig.ready() from running twice Is there a python singleton pattern which might work? /Connected by Motorola/ Melvyn Sopacua wrote: On donderdag 21 juni 2018 16:23:23 CEST clavierpla...@gmail.com wrote: > If it helps, here is the reason I need to override this multi-instantiation > behavior: my application launches a multiprocessing.Process at startup to > monitor and run background tasks. Having more than one background Process > running at once is going to wreak havoc on the application. I've looked at > other options to accomplish similar purposes, but those would all be > instantiated multiple times, also. > > Any suggestions? Use a locked pidfile to prevent multiple daemons starting up. I recall the python-daemon package being capable of this (and lots of other good stuff). https://pagure.io/python-daemon/ -- Melvyn Sopacua -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/139066525.eYAS18T7Ez%40fritzbook. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com <mailto:django-users+unsubscr...@googlegroups.com>. To post to this group, send email to django-users@googlegroups.com <mailto:django-users@googlegroups.com>. Visit this group at https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/wb0bbtt2xa79lb1b10sny7md.1529712066075%40email.android.com <https://groups.google.com/d/msgid/django-users/wb0bbtt2xa79lb1b10sny7md.1529712066075%40email.android.com?utm_medium=email_source=footer>. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com <mailto:django-users+unsubscr...@googlegroups.com>. To post to this group, send email to django-users@googlegroups.com <mailto:django-users@googlegroups.com>. Visit this group at https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/DB7P193MB0331E4C4C900D305CF7AA1308C740%40DB7P193MB0331.EURP193.PROD.OUTLOOK.COM <https://groups.google.com/d/msgid/django-users/DB7P193MB0331E4C4C900D305CF7AA1308C740%40DB7P193MB0331.EURP193.PROD.OUTLOOK.COM?utm_medium=email_source=footer>. For more options, visit https://groups.goog
Re: prevent AppConfig.ready() from running twice
IMHO, some of (a lot of ?) the "classical" GOF patterns do not really apply to Python (or at least are not necessary, when not making things more confuse). They are often a consequence of constraints and limitations of statically compiled languages such as C++, Java and alike used at the time they have been created, but they loose most of their interest for languages such as Python. If the singleton instance is used internally by your application code, and apart if you have really good reasons for making things more complicated, juts use a module level variable to store the instance, and initialize it at application start. Of course, forbid yourself to write to this variable from elsewhere than the app initialization code. If the singleton creation can be called from other places (f.i. if a lazy initialization strategy is used), and if there are possibilities for it to be called several times, a guard can be implemented by providing a factory function which will test if the instance is currently None, instantiate one if needed, store it in the module variable, and return the module variable at the end. It would look like this: _singleton_instance = None def get_singleton(): if _singleton_instance is None: _singleton_instance = return _singleton_instance The '_' prefix of the singleton variable is use to indicate that this is a "private" variable which must not be referred to (even in read access) from outside the module. Hope this helps. Regards Eric From: django-users@googlegroups.com on behalf of Mike Dewhirst Sent: Saturday, June 23, 2018 2:01:06 AM To: django-users@googlegroups.com Subject: Re: prevent AppConfig.ready() from running twice Is there a python singleton pattern which might work? Connected by Motorola Melvyn Sopacua wrote: On donderdag 21 juni 2018 16:23:23 CEST clavierpla...@gmail.com wrote: > If it helps, here is the reason I need to override this multi-instantiation > behavior: my application launches a multiprocessing.Process at startup to > monitor and run background tasks. Having more than one background Process > running at once is going to wreak havoc on the application. I've looked at > other options to accomplish similar purposes, but those would all be > instantiated multiple times, also. > > Any suggestions? Use a locked pidfile to prevent multiple daemons starting up. I recall the python-daemon package being capable of this (and lots of other good stuff). https://pagure.io/python-daemon/ -- Melvyn Sopacua -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/139066525.eYAS18T7Ez%40fritzbook. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com<mailto:django-users+unsubscr...@googlegroups.com>. To post to this group, send email to django-users@googlegroups.com<mailto:django-users@googlegroups.com>. Visit this group at https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/wb0bbtt2xa79lb1b10sny7md.1529712066075%40email.android.com<https://groups.google.com/d/msgid/django-users/wb0bbtt2xa79lb1b10sny7md.1529712066075%40email.android.com?utm_medium=email_source=footer>. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/DB7P193MB0331E4C4C900D305CF7AA1308C740%40DB7P193MB0331.EURP193.PROD.OUTLOOK.COM. For more options, visit https://groups.google.com/d/optout.
Re: prevent AppConfig.ready() from running twice
Is there a python singleton pattern which might work? Connected by Motorola Melvyn Sopacua wrote: >On donderdag 21 juni 2018 16:23:23 CEST clavierpla...@gmail.com wrote: > >> If it helps, here is the reason I need to override this multi-instantiation >> behavior: my application launches a multiprocessing.Process at startup to >> monitor and run background tasks. Having more than one background Process >> running at once is going to wreak havoc on the application. I've looked at >> other options to accomplish similar purposes, but those would all be >> instantiated multiple times, also. >> >> Any suggestions? > >Use a locked pidfile to prevent multiple daemons starting up. I recall the >python-daemon package being capable of this (and lots of other good stuff). > >https://pagure.io/python-daemon/ >-- >Melvyn Sopacua > >-- >You received this message because you are subscribed to the Google Groups >"Django users" group. >To unsubscribe from this group and stop receiving emails from it, send an >email to django-users+unsubscr...@googlegroups.com. >To post to this group, send email to django-users@googlegroups.com. >Visit this group at https://groups.google.com/group/django-users. >To view this discussion on the web visit >https://groups.google.com/d/msgid/django-users/139066525.eYAS18T7Ez%40fritzbook. >For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/wb0bbtt2xa79lb1b10sny7md.1529712066075%40email.android.com. For more options, visit https://groups.google.com/d/optout.
Re: prevent AppConfig.ready() from running twice
On donderdag 21 juni 2018 16:23:23 CEST clavierpla...@gmail.com wrote: > If it helps, here is the reason I need to override this multi-instantiation > behavior: my application launches a multiprocessing.Process at startup to > monitor and run background tasks. Having more than one background Process > running at once is going to wreak havoc on the application. I've looked at > other options to accomplish similar purposes, but those would all be > instantiated multiple times, also. > > Any suggestions? Use a locked pidfile to prevent multiple daemons starting up. I recall the python-daemon package being capable of this (and lots of other good stuff). https://pagure.io/python-daemon/ -- Melvyn Sopacua -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/139066525.eYAS18T7Ez%40fritzbook. For more options, visit https://groups.google.com/d/optout.
prevent AppConfig.ready() from running twice
Hello, I am still new to Django, so I apologize if this seems like a silly question. I've not been able to find what I need on Google, StackOverflow, or the Django Docs. I am using Django 2.0.5. I understand that the correct way to run startup code is to subclass AppConfig and override ready(). I also understand that Django launches two separate instances of the application--one to check the models, and the other to launch the server--on separate processes. The official recommendation to prevent startup code from being run more than once is to implement a flag--which can't work if there are multiple instances of the application being created. The docs also say that ready() will be re-called only rarely; but this doesn't help at all if all of the instances are calling ready() only once. I have found the manage.py runserver --noreload command, but this won't be enough to prevent multiple instances on a production server. What can I do to enforce one and only one instance of my application being run at a time? If it helps, here is the reason I need to override this multi-instantiation behavior: my application launches a multiprocessing.Process at startup to monitor and run background tasks. Having more than one background Process running at once is going to wreak havoc on the application. I've looked at other options to accomplish similar purposes, but those would all be instantiated multiple times, also. Any suggestions? Thank you, Heather -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/6d8729fe-18c4-4e53-8479-c2b9dd178b89%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
