Shulou(Shulou.com)06/03 Report--

This article shares with you the content of a sample analysis of initialization initiated by APScheduler in django-xadmin. The editor thinks it is very practical, so share it with you as a reference and follow the editor to have a look.

Environment: python3.5.x + django1.9.x + xadmin-for-python3

APScheduler, as a lightweight and heavily used background task scheduling (scheduler) package, can be easily started / shut down when the system starts / shuts down. If integrated into django, where should the code to start APScheduler be written?

The following ways are for reference:

1. (recommended) Custom Middleware, which is very similar to Filter in Java. The disadvantage is that you need URL access to trigger startup. If you visit URL before the system is started, it will trigger multiple calls to _ _ init__ (caused by multiple http requests). You can synchronize the code and status limit through threading's lock once.

Class StartupMiddleware (object): def _ init__ (self): # start background task APScheduler init_scheduler () from django.core.exceptions import MiddlewareNotUsed raise MiddlewareNotUsed # TIP throws this exception, Django will remove the middleware from the middleware stack The request will not go through this middleware def process_request (self, request): print ("* enter startup middleware") scheduler = Nonedef init_scheduler (): global scheduler lock = threading.Lock () # TIP multithreading synchronization code with lock: if scheduler and scheduler.running: print ('* APScheduler is already started, pid: {}, tid: {} '.format (os.getpid ()) Threading.current_thread () .getName () return scheduler executors = {'default': ThreadPoolExecutor (5), # process pool size in threaded mode' processpool': ProcessPoolExecutor (5), # process pool size in process mode} job_defaults = {'coalesce': True, # if several times have not been executed Whether to execute 'max_instances': 1, # at most several instances of the same job at the same time} scheduler = BackgroundScheduler (executors=executors, job_defaults=job_defaults, timezone=timezone (TIME_ZONE)) scheduler.add_job (...) Scheduler.start () return scheduler

two。 For the settings.py file in the application, django starts two python processes by default in the development environment (it is still very practical for the development environment, and it will restart automatically after changing the code). The code in settings.py will be called by both python processes once, of course, you can start only one python process through the-- reload parameter. In addition, some of the app has not been loaded when loading settings.py, which limits the code of the application.

3. The top-level urls file, no matter whether you start django with one process or two processes, the urls file will only be loaded once, but the drawback is that when executing commands like makemigrations, there will be the same error that app has not been loaded.

Thank you for reading! This is the end of this article on "sample analysis of APScheduler startup initialization in django-xadmin". I hope the above content can be of some help to you, so that you can learn more knowledge. if you think the article is good, you can share it for more people to see!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.