Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix maintenance task issues raised in #2005 #2020

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

dams
Copy link

@dams dams commented Dec 30, 2023

  • share 'last_cleaned_at' between workers and set it at maintenance task start time
  • release maintenance lock when maintenance task is finished

@dams dams force-pushed the dams/fix_maintenance_task branch 3 times, most recently from 3b01892 to ee4f661 Compare December 30, 2023 16:44
- share 'last_cleaned_at' between workers and set it at maintenance task start time
- release maintenance lock when maintenance task is finished
Copy link

codecov bot commented Dec 30, 2023

Codecov Report

Attention: 1 lines in your changes are missing coverage. Please review.

Comparison is base (a820939) 93.84% compared to head (aed76e9) 93.81%.

Files Patch % Lines
rq/worker_registration.py 90.00% 1 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##           master    #2020      +/-   ##
==========================================
- Coverage   93.84%   93.81%   -0.04%     
==========================================
  Files          29       29              
  Lines        3901     3911      +10     
==========================================
+ Hits         3661     3669       +8     
- Misses        240      242       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.


def set_last_cleaned_at(last_cleaned_at: datetime, connection: 'Redis'):
"""Sets the last time maintenance task was run."""
connection.set('last_cleaned_at', utcformat(last_cleaned_at))
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mind storing this as UTC timestamp instead of string?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How do I do that?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maintenance tasks should run on first startup or every maintenance
interval (defaults to 10 minutes).
"""
l_c_at = self.last_cleaned_at = self.last_cleaned_at or worker_registration.get_last_cleaned_at(self.connection)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we're storing the last cleaning time at self.last_cleaned_at, we don't need l_c_at variable.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

l_c_at is there just for having a shorter line below

@selwin
Copy link
Collaborator

selwin commented Jan 13, 2024

Actually I just realized something, the cleaning timestamp has to be done on a per queue basis and not RQ wide. It could be that we have different workers working on different queues.

@dams
Copy link
Author

dams commented Jan 13, 2024

Actually I just realized something, the cleaning timestamp has to be done on a per queue basis and not RQ wide. It could be that we have different workers working on different queues.

Unless I did it wrong, my changes store the cleaning timestamp per worker and the cleaning will be done on all the queues of this worker. It's not a RQ wide timestamps. So I think it'll work just fine

@selwin
Copy link
Collaborator

selwin commented Jan 13, 2024

Unless I did it wrong, my changes store the cleaning timestamp per worker and the cleaning will be done on all the queues of this worker. It's not a RQ wide timestamps. So I think it'll work just fine

If I have 10 workers running rq worker high and 1 worker running rq worker low, all the workers will store their last maintenance timestamp at the same rq:workers:last_cleaned_at key. Chances are that the low queue will not be cleaned for a long time.

@selwin
Copy link
Collaborator

selwin commented Jan 13, 2024

If I have 10 workers running rq worker high and 1 worker running rq worker low, all the workers will store their last maintenance timestamp at the same rq:workers:last_cleaned_at key. Chances are that the low queue will not be cleaned for a long time.

Please also write a test for this scenario.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants