The RPC call is failing because the binding between the destination exchange and queue no longer exists. This causes the RPC call to "black hole" the published request.
Yeah, if that is the case then option a.) sounds like the most feasible approach.
I tried simulating this using a test RPC client and server: after the server establishes the exchange-binding-queue I used rabbitmqadmin to delete just the binding. This results in all following RPC calls to time out.
I then modified my RPC client to pass in that transport option:
This change will cause the RPC call to immediately fail with a MessageUndeliverable exception.
However this doesn't fix the binding. When the binding is deleted the RPC _server_ gets no notification that anything is wrong, probably because the server simply subscribes to a queue after setting up the binding and as far as the server is concerned that queue is doing just fine.
Since there's no event occurring on the _server_ side I'm not sure if oslo.messaging can detect this particular problem and recover automagically.
Just to make sure my understanding is correct:
The RPC call is failing because the binding between the destination exchange and queue no longer exists. This causes the RPC call to "black hole" the published request.
Yeah, if that is the case then option a.) sounds like the most feasible approach.
I tried simulating this using a test RPC client and server: after the server establishes the exchange- binding- queue I used rabbitmqadmin to delete just the binding. This results in all following RPC calls to time out.
I then modified my RPC client to pass in that transport option:
_topts = messaging. TransportOption s(at_least_ once=True) RPCClient( self.transport,
self. target,
timeout= conf.timeout,
version_ cap=conf. target_ version,
transport_ options= _topts) .prepare( )
client = messaging.
This change will cause the RPC call to immediately fail with a MessageUndelive rable exception.
However this doesn't fix the binding. When the binding is deleted the RPC _server_ gets no notification that anything is wrong, probably because the server simply subscribes to a queue after setting up the binding and as far as the server is concerned that queue is doing just fine.
Since there's no event occurring on the _server_ side I'm not sure if oslo.messaging can detect this particular problem and recover automagically.