How to test if cluster is running

[SchrodingersGat]

Sorry if this is a silly question.

I want to be able to determine from within my django app if there are any q clusters running. i.e. "is someone going to service my tasks".

I thought the monitor docs covered this, specifically:

from django_q.monitor import Stat

for stat in Stat.get_all():
    print(stat.cluster_id, stat.status)

However, Stat.get_all() simply returns []

Some details:

• I have a cluster running (and tasks are getting serviced) using python manage.py qcluster
• Running on Windows under WSL
• I have set sync=True
• Using ORM as the database

Setup in settings.py:

# django-q configuration
Q_CLUSTER = {
    'name': 'myappname,
    'workers': 4,
    'timeout': 90,
    'retry': 120,
    'queue_limit': 50,
    'bulk': 10,
    'orm': 'default',
    'sync': True,
}

Am I on the right path here, or is there a different function I should use?

[Koed00]

If you have sync=True the code will be executed by the local django instance, not by the cluster instance. Try setting sync=False. That said, the stat should still return data, so probably something else is wrong too.

[pysean3]

Do you have caching setup for django? It's real easy to set up the database backed cache and don't forget to run the create cache table command. The monitoring doesn't work without it and the Stat class will return the empty dictionary in my experience.

[SchrodingersGat]

Hi @pysean3 do you mean this django caching? Can I set up a simple RAM cache and then the Stat should work?

Currently this is in my settings.py file:

[ali-mhz]

I set "sync": False and also i set caching to database and also created the cache table. Now whenever i run qcluster command a new row will be inserted in the table but still Stat.get_all() returns []

[pysean3]

@SchrodingersGat, yes, I meant the regular django caching. I use the ORM as the broker, the database cache in django, and all works well. Just be sure to run the python manage.py createcachetable management command to actually create the table. And, you need the cluster to be actually running to populate the cache. I assume the ram cache would work also, but not ideal if you're using on multiple machines. You can try with the database backend and see if that works.

@ali-mhz, do you get data when running python manage.py qmonitor or python manage.py qinfo? If not, then get those working first. The setup of cache was key for me to get it working. That, and be sure the cluster is actually running via python manage.py qcluster. Otherwise, no data will be populated. And, there is a second or two delay between calling Stat.get_all() and the resulting dictionary actually being populated/updated when the cluster is started/stopped. Just something to keep in mind.

[SchrodingersGat]

Strangely I am getting mixed results based on the very helpful suggestions above.

• I have run the python manage.py createcachetable command
• I am running the background cluster with python manage.py qcluster
• Scheduled tasks are working perfectly
• Stat.get_all() returns an empty list

Here are the scheduled tasks in the admin interface:

Here is the output of qinfo

And qmonitor

As a "workaround" I have added a heartbeat schedule task which runs every 5 minutes - and the "success" of this task can be queried from the DB to determine if the background worker has been running in the last 5 minutes.

I would like to work out why the Stat command is not working though.

[pysean3]

I haven't had a chance to figure out why yet, but the Stat class for the ORM broker seems to only be populated when the name of the cluster in the settings is kept the same as in the docs as: 'name': 'DjangORM' (note the missing o in Django)

Any other name, the worker runs fine, but the qmonitor doesn't pick it up either. I thought I noticed that a while back but just changed the cluster name back to the default and forgot about it. Seems there is an older issue also regarding it also. #277

Try changing the cluster name and see if that works perhaps?

[ali-mhz]

It worked for me. It just took some seconds. I was checking immediately but after reading @pysean3 comment i waited and then i got result.

@ali-mhz, do you get data when running python manage.py qmonitor or python manage.py qinfo? If not, then get those working first. The setup of cache was key for me to get it working. That, and be sure the cluster is actually running via python manage.py qcluster. Otherwise, no data will be populated. And, there is a second or two delay between calling Stat.get_all() and the resulting dictionary actually being populated/updated when the cluster is started/stopped. Just something to keep in mind.

[SchrodingersGat]

Try changing the cluster name and see if that works perhaps?

Changing the cluster name to "DjangORM" did not fix the issue for me.

[aaronoppenheimer]

I'm having the same result as @SchrodingersGat with the same setup.

[muthu5elvan]

Hi, I also face the same problem and saw one useful piece of information on the Django documentation page. https://docs.djangoproject.com/en/4.0/topics/cache/

I change my cache configuration to Django ORM in setting.py like below then i run python manage.py createcachetable command to create a table

i think now it is working fine

[SchrodingersGat]

I might have an insight here - I think it is due to using django.core.cache.backends.locmem.LocMemCache as the cache backend.

From the django documentation:

Note that each process will have its own private cache instance, which means no cross-process caching is possible.

As the qcluster is a different process to the django server, or the monitoring process, they will not have access to the same cache data. Would this explain why it does not work with LocMemCache?