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 update tasks #3958

Merged
merged 9 commits into from Apr 10, 2017
Merged

Fix update tasks #3958

merged 9 commits into from Apr 10, 2017

Conversation

brianmay
Copy link
Contributor

@brianmay brianmay commented Apr 5, 2017

#3791 was improved and become #3890. This is an improvement on #3890, as it addresses some of the feedback supplied there.

Checks if the heap is valid. If there are changes in scheduled tasks the heap is populated again.

This means, when using django-celery-beat, changes to the periodictask table are automatically detected without restarting celery.

Fixes celery/django-celery-beat#7

I can squash/rebase/split/reformat/turn-into-a-penguin as required.

@brianmay
Copy link
Contributor Author

brianmay commented Apr 5, 2017

Just updated this to fix some of the problems I encountered. Should work now regardless of how you change the schedule.

celery/beat.py Outdated
b_model = b.get(name)
if not b_model:
return False
if model.schedule != b_model.schedule:
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This code looks like it is specific the Django DB models used in django_celery_beat. May not be appropriate to include in celery???

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Oh, wait, my objection to my own pull request might be unfounded.

django_celery_beat.schedulers.ModelEntry is actually inherited from celery.beat ScheduleEntry - so I am guessing is actually a standard celery object with some extra bits added.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I believe the above code is fine.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

For the record, on this line we are comparing two celery.schedules.schedule objects (for interval times) or two celery.schedules.crontab objects (for crontab entries). Or maybe one of each (if the user has just changed from one to the other).

Copy link
Member

@thedrow thedrow left a comment

Choose a reason for hiding this comment

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

Minor comments.
Also, can we add tests for schedules_equal?

celery/beat.py Outdated
def schedules_equal(self, a, b):
if set(a.keys()) != set(b.keys()):
return False
for name, model in a.items():
Copy link
Member

Choose a reason for hiding this comment

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

I think entry is a better name than model. Models are specific to ORMs.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, agreed. Probably partly responsible for my confusion above.

celery/beat.py Outdated
return False
for name, model in a.items():
b_model = b.get(name)
if not b_model:
Copy link
Member

Choose a reason for hiding this comment

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

There's no need for a separate if statement here. Use or instead.

celery/beat.py Outdated
@@ -281,6 +284,17 @@ def tick(self, event_t=event_t, min=min, heappop=heapq.heappop,
return min(verify[0], max_interval)
return min(adjust(next_time_to_run) or max_interval, max_interval)

def schedules_equal(self, a, b):
Copy link
Member

Choose a reason for hiding this comment

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

Let's use more meaningful names here. old_schedule and new_schedule works imo.

@brianmay
Copy link
Contributor Author

brianmay commented Apr 9, 2017

Have addressed minor issues. Will see if I can do anything about tests.

@brianmay
Copy link
Contributor Author

brianmay commented Apr 10, 2017

In writing a test, I found that when we assign schedule to old_schedule we copy the reference to the dictionary. So if you mutate the dictionary - as happens by default with the methods provided - you compare the dictionary with itself. I have now changed that to do a shallow copy of the dictionary.

Otherwise, if we mutate the dictionary (e.g. using provided methods),
we won't see any changes.
@brianmay
Copy link
Contributor Author

Ok, just pushed tests. Have confirmed that the test to check the schedule change works breaks without this change.

@brianmay
Copy link
Contributor Author

brianmay commented Apr 10, 2017

In doing a shallow copy, I am making the assumption that that the ScheduleEntry objects (and nested schedule objects) will not get mutated. Which is probably correct, but can't be guaranteed, especially as the ScheduleEntry object has an update() method, designed to mutate its state.

I tried using copy.deepcopy also, but this doesn't work here.

@brianmay
Copy link
Contributor Author

It looks like travis crashed before it even got to running the tests.

@georgepsarakis
Copy link
Contributor

@brianmay I restarted the failed job.

@thedrow thedrow merged commit b27c0f1 into celery:master Apr 10, 2017
@thedrow
Copy link
Member

thedrow commented Apr 10, 2017

Thanks. Feel free to add yourself to the AUTHORS file.

@brianmay brianmay deleted the fix_update_tasks branch April 10, 2017 23:03
brianmay added a commit to brianmay/celery that referenced this pull request Apr 10, 2017
georgepsarakis pushed a commit that referenced this pull request Apr 11, 2017
@evasilchenko
Copy link

Are there plans to get this fix into an official new release soon?

@thedrow
Copy link
Member

thedrow commented Apr 17, 2017

Yes. It will land on the next release.

@brianmay
Copy link
Contributor Author

When is the next release due? Are there any obstacles in the way of a release?

@thedrow
Copy link
Member

thedrow commented May 28, 2017

We're working on it. Right now debating about a merged pull request with possible security issues. See celery/py-amqp#146 (comment)

@Gurubol
Copy link

Gurubol commented Jun 11, 2017

@thedrow , Looks like the security issue you were talking about is closed. Can we please know when will this fix be released? Thanks.

@thedrow
Copy link
Member

thedrow commented Jun 11, 2017

I'm trying to reach @ask to provide us with release access. I'll let you know once it happens.

thedrow pushed a commit to staticfox/celery that referenced this pull request Jul 6, 2017
@elyssonmr
Copy link

Hello guys!
I'm trying to build a "task agenda" and I'm going to need this fix... there is any release date planned?
I saw last comment dated from 29 days ago (when I wrote this comment).

Thanks :D

@thedrow
Copy link
Member

thedrow commented Jul 10, 2017

We're unable to reach the maintainer with the release rights. I don't have an ETA for the release.

@brianmay
Copy link
Contributor Author

@thedrow I assume you mean you can't upload to PyPI? If so, maybe contact PyPI admin and see if they can help? In the meantime maybe you could do the other steps of a release, e.g. use bumpversion to increment the version and add a git tag. Thanks.

@mheppner
Copy link

@thedrow Slightly related, but #4100 could use some feedback on who the project maintainers are and who has release rights.

@sreecodeslayer
Copy link

I want this one released so badly ☹️

@thedrow
Copy link
Member

thedrow commented Nov 8, 2017

@sreecodeslayer This was released as part of 4.1.0 a while ago.

@Gurubol
Copy link

Gurubol commented Nov 8, 2017

@thedrow , I see that the build has failed. Please check status at https://travis-ci.org/celery/celery/jobs/299003848 for the build at https://travis-ci.org/celery/celery

Can you please clarify?

@thedrow
Copy link
Member

thedrow commented Nov 9, 2017

We're aware that the build has failed.
We'll look into it once we have the time to do so.

@brianmay
Copy link
Contributor Author

In my latest testing, it seems that I still have issues with the schedule not being reloaded in master :-(
That is when I modify a crontab database entry, I have to restart beat for the changes to have affect. Will do some more testing.

@brianmay
Copy link
Contributor Author

brianmay commented Nov 12, 2017

Just set a task to run every 2 minutes. It runs the first time, but then fails to run again until restarting celery. This is with master. Will try downgrading to the most recent stable version and see if that helps.

@brianmay
Copy link
Contributor Author

Me confused, celery 4.1.0 doesn't seem to be running interval tasks at all. Was working last time I tested it. Will concentrate my efforts on master.

@brianmay
Copy link
Contributor Author

brianmay commented Nov 12, 2017

In master, changing the periodic task to point to a different interval or crontab object results in an instant change, but changing the interval object or crontab itself doesn't. Curious, as this is a case a tested in the pull request. Also the task - if it is an interval - only gets run once. Also curious.

@brianmay
Copy link
Contributor Author

brianmay commented Nov 12, 2017

Oops, just realised a new version of django-celery-beat (1.1.0) was released 13 days ago. Apologies for the noise.

The schedule now reloads as required. However I still have this issue where a interval based task only runs once (after restarting task or updating the schedule).

@thedrow
Copy link
Member

thedrow commented Nov 13, 2017

@brianmay Please open a new issue if one doesn't exist for the problem you are describing.

@brianmay
Copy link
Contributor Author

@thedrow, ok will do so.

@CharmingYang0
Copy link

@brianmay
Hopefully, this fix will be involved in celery 4.1.1 and this version is released soon.

@auvipy auvipy added this to the v4.2 milestone Jan 17, 2018
SebastianBerchtold pushed a commit to smartlane/celery that referenced this pull request Jun 11, 2018
@vilhelmen vilhelmen mentioned this pull request Jul 26, 2023
4 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet