Merge lp:~abentley/launchpad/restore-queue-test into lp:launchpad
Status: | Merged |
---|---|
Approved by: | Aaron Bentley |
Approved revision: | no longer in the source branch. |
Merged at revision: | 15684 |
Proposed branch: | lp:~abentley/launchpad/restore-queue-test |
Merge into: | lp:launchpad |
Diff against target: |
289 lines (+125/-24) 8 files modified
lib/lp/services/config/schema-lazr.conf (+7/-1) lib/lp/services/job/celeryconfig.py (+5/-1) lib/lp/services/job/celeryjob.py (+32/-14) lib/lp/services/job/runner.py (+1/-1) lib/lp/services/job/tests/celery_helpers.py (+12/-1) lib/lp/services/job/tests/test_celery_configuration.py (+2/-1) lib/lp/services/job/tests/test_celeryjob.py (+65/-4) lib/lp/services/job/tests/test_runner.py (+1/-1) |
To merge this branch: | bzr merge lp:~abentley/launchpad/restore-queue-test |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Richard Harding (community) | Approve | ||
Review via email: mp+116534@code.launchpad.net |
Commit message
Fix bug #1015667: Celery is leaving an ever increasing number of queues behind
Description of the change
= Summary =
Fix bug #1015667: Celery is leaving an ever increasing number of queues behind
== Proposed fix ==
Re-apply the changes from r15656, and fix the test.
== Pre-implementation notes ==
None
== LOC Rationale ==
Reverting a rollback
== Implementation details ==
Add polling to ensure that list_queued does not race with RabbitMQ message delivery.
Replace existing polling by waiting for a no-op task.
== Tests ==
bin/test -t test_run_
== Demo and Q/A ==
Enable Celery and celery-based branch scanning on qastaging. Run for at least an hour. No mysterious queues should be left behind.
= Launchpad lint =
Checking for conflicts and issues in changed files.
Linting changed files:
lib/lp/
lib/lp/
lib/lp/
lib/lp/
lib/lp/
lib/lp/
lib/lp/
lib/lp/
./lib/lp/
445: Line exceeds 80 characters.
1038: Line exceeds 80 characters.
1045: Line exceeds 80 characters.
1583: Line exceeds 80 characters.
Thanks for the update Aaron.
Only comments are would it make sense for the db user to be an attribute of the job class for the _init_task() call so that there's some context on what that string is.
Would the noop task be more a test helper and be specific to that vs in the list of normal jobs or is it logical that someone might want to use it for actual regular processing at some point?
Finally, the TransactionFree Operation is a bit confusing as I'd not expect the transaction.commit at the end of something that's not a transaction? Looking at the object, it appears to just be something that says there aren't any current active transactions, so is this just guarding against multiple transactions stomping on each other? Since this is copied from the old code and not pertaining the queues, marking approved but appreciate any education lesson on this front.