Merge lp:~vila/uci-engine/unique-queues into lp:uci-engine
Proposed by
Vincent Ladeuil
Status: | Merged |
---|---|
Approved by: | Vincent Ladeuil |
Approved revision: | 863 |
Merged at revision: | 862 |
Proposed branch: | lp:~vila/uci-engine/unique-queues |
Merge into: | lp:uci-engine |
Diff against target: |
83 lines (+9/-9) 4 files modified
lander/lander/tests/test_service_wrapper.py (+3/-3) lander/lander/workflow.py (+2/-2) test_runner/bin/check_worker.py (+2/-2) test_runner/run-integration.py (+2/-2) |
To merge this branch: | bzr merge lp:~vila/uci-engine/unique-queues |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
PS Jenkins bot (community) | continuous-integration | Approve | |
Paul Larson | Approve | ||
Review via email: mp+239462@code.launchpad.net |
Commit message
Always use unique queue names for progress report
Description of the change
When running at scale, time.time() to "uniquify" a queue name is not enough, multiple workers can call time.time() at the same... time.
I ran into this while debugging uci-britney and ending up with orphaned queues that still had unprocessed messages.
'prefetch' was adding to the confusion but this collision on queue names is also a nasty trap that is hard to encounter with deployments with a single unit of each type (or even two for the lander).
To post a comment you must log in.
You may want to consider uuid4 instead of uuid1. IIRC uuid1 generates the uuid based on mac address and time... so if these happen on the same node at the same time, I think you could still risk collision right?
Something to consider, but if you know a good reason why that's not a risk, feel free. uuid4 is just a straight pseudorandom uuid, which isn't wonderful, but possibly a better fit here.
Otherwise +1 from me