summaryrefslogtreecommitdiff
path: root/docs/faq.rst
blob: baac05a2ab9062f33ab10171290f3061faad903d (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
##########################
Frequently Asked Questions
##########################

Why doesn't the scheduler run my jobs?
======================================

This could be caused by a number of things. The two most common issues are:

#. Running the scheduler inside a uWSGI worker process while threads have not been enabled (see the
   next section for this)
#. Running a :class:`~apscheduler.schedulers.background.BackgroundScheduler` and then letting the
   execution reach the end of the script

To demonstrate the latter case, a script like this will **not work**::

    from apscheduler.schedulers.background import BackgroundScheduler

    def myjob():
        print('hello')

    scheduler = BackgroundScheduler()
    scheduler.start()
    scheduler.add_job(myjob, 'cron', hour=0)

The script above will **exit** right after calling ``add_job()`` so the scheduler will not have a
chance to run the scheduled job.

If you're having any other issue, then enabling debug logging as instructed in the
:ref:`troubleshooting` section should shed some light into the problem.

Why am I getting a ValueError?
==============================

If you're receiving an error like the following::

   ValueError: This Job cannot be serialized since the reference to its callable (<bound method xxxxxxxx.on_crn_field_submission
   of <__main__.xxxxxxx object at xxxxxxxxxxxxx>>) could not be determined. Consider giving a textual reference (module:function
   name) instead.

This means that the function you are attempting to schedule has one of the following problems:

* It is a lambda function (e.g. ``lambda x: x + 1``)
* It is a bound method (function tied to a particular instance of some class)
* It is a nested function (function inside another function)
* You are trying to schedule a function that is not tied to any actual module (such as a function
  defined in the REPL, hence ``__main__`` as the module name)

In these cases, it is impossible for the scheduler to determine a "lookup path" to find that
specific function instance in situations where, for example, the scheduler process is restarted,
or a process pool worker is being sent the related job object.

Common workarounds for these problems include:

* Converting a lambda to a regular function
* Moving a nested function to the module level or to class level as either a class method or a
  static method
* In case of a bound method, passing the unbound version (``YourClass.method_name``) as the target
  function to ``add_job()`` with the class instance as the first argument (so it gets passed as the
  ``self`` argument)

How can I use APScheduler with uWSGI?
=====================================

uWSGI employs some tricks which disable the Global Interpreter Lock and with it, the use of threads
which are vital to the operation of APScheduler. To fix this, you need to re-enable the GIL using
the ``--enable-threads`` switch. See the `uWSGI documentation <uWSGI-threads>`_ for more details.

Also, assuming that you will run more than one worker process (as you typically would in
production), you should also read the next section.

.. _uWSGI-threads: https://uwsgi-docs.readthedocs.io/en/latest/WSGIquickstart.html#a-note-on-python-threads

How do I use APScheduler in a web application?
==============================================

If you're running Django, you may want to check out django_apscheduler_. Note, however, that this
is a third party library and APScheduler developers are not responsible for it.

Likewise, there is an unofficial extension called Flask-APScheduler_ which may or may not be useful
when running APScheduler with Flask.

For Pyramid users, the pyramid_scheduler_ library may potentially be helpful.

Other than that, you pretty much run APScheduler normally, usually using
:class:`~apscheduler.schedulers.background.BackgroundScheduler`. If you're running an asynchronous
web framework like aiohttp_, you probably want to use a different scheduler in order to take some
advantage of the asynchronous nature of the framework.

Is there a graphical user interface for APScheduler?
====================================================

No graphical interface is provided by the library itself. However, there are some third party
implementations, but APScheduler developers are not responsible for them. Here is a potentially
incomplete list:

* django_apscheduler_
* apschedulerweb_
* `Nextdoor scheduler`_

.. _django_apscheduler: https://pypi.org/project/django-apscheduler/
.. _Flask-APScheduler: https://pypi.org/project/flask-apscheduler/
.. _pyramid_scheduler: https://github.com/cadithealth/pyramid_scheduler
.. _aiohttp: https://pypi.org/project/aiohttp/
.. _apschedulerweb: https://github.com/marwinxxii/apschedulerweb
.. _Nextdoor scheduler: https://github.com/Nextdoor/ndscheduler