Bryan Talbot wrote:
I believe that if I remove the binding and then re-add it with the new selector, any messages processed during that time will not get into the (then unbound) destination.
Correct.
Bryan Talbot wrote:
The least good solution is to stop all message production to the composite queue.
There is no other way currently if you want to be absolutely sure to lose no message. You could create a short CLI script to delete and recreate a binding. At least there would be minimal delay between the 2 commands if you execute it with clis.
Bryan Talbot wrote:
Another option would be to allow for multiple bindings to the same destination with different selectors. This would allow me to just keep adding new bindings instead of needing to update an existing one.
The queue name is the name of the binding and it must be unique, sorry...