allow payload length filtering
Bug #1908876 reported by
norman shen
This bug affects 1 person
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| oslo.messaging |
New
|
Undecided
|
Unassigned | ||
Bug Description
In one of our production environment, I saw unexpected long notification from cinder backup. It is mainly caused by cinder backup is backing up a very huge volume (>1T) and got too many slices (object size is 48MB configured).
Rabbitmq had hard time handling very large objects and what's worse is that we are using a mirroring queue setup.
So I thinking if it is possible to create a filter which will filter out unexpected message passed by program, by doing this in oslo.messaging, individual users do not have to implement their own logics.
Revision history for this message
| Ken Giusti (kgiusti) wrote | #1 |
Revision history for this message
| Ken Giusti (kgiusti) wrote | #2 |
To post a comment you must log in.
> Rabbitmq had hard time handling very large objects and what's worse is that we are using a mirroring queue setup.
How does the failure manifest? RPC timeout/call failure?
What will happen if the messages are filtered? Won't that result in an RPC timeout/call failure as well?
I'm not sure that adding a filter feature to oslo.messaging will provide any value here.
Since 3.8+ (IIUC) rabbitmq has a configurable maximum message size (up to 512MB per message). What happens if the size limit is set in rabbitmq to < 48BM? Does that effectively do the same thing as having a filter in oslo.messaging?
Can the cinder object size be reduced?