Ubuntu CI Engine

nacking a rabbit message is not enough to have another consumer get it

Bug #1320205 reported by Vincent Ladeuil
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Ubuntu CI Engine
Triaged
Medium
Unassigned
Ubuntu CI Engine backlog

Bug Description

Discovered when fixing bug #1320000 , nacking a message put it back on the queue but since we use prefetch_count=1 in baisc_qos() the message stays in the local queue and doesn't "go back" to the server.

We need to either:
- stop using prefetch_count=1 (rabbit's doc says it's good for performance reasons),
- change out implementation to also close the queue/channel/connection and reopen
- something else

Tags: airline
Revision history for this message
Vincent Ladeuil (vila) wrote :

Experimenting with amqp for the debci, pitti had a test showing that killing the worker put the not-yet-acked message back to the queue.

Revision history for this message
Vincent Ladeuil (vila) wrote :

Not that we don't currently nack messages in the code, we've only talked about using such a facility.

What we do support for now is what rabbit gives us: until we explicitly ack the message, if the worker dies, the message "goes back" to the server and we know another worker will get it (such other worker may be the "same"[1] if it's restarted though).

(This was mentioned in the review for bug #1320000 but not in this bug).

[1]: Same hardware or same network address for example.

Changed in uci-engine:
importance: High → Medium
Vincent Ladeuil (vila)
Changed in uci-engine:
milestone: uce-0 → backlog
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.