Hi @Tamimi , thank you — your explanation definitely helps!
In my case as well, I expect the topic subscriptions to be configured on the queues administratively ahead of time, so withSubscriptions at runtime is not really an option if it’s going to try adding those subscriptions as well. Besides, the non-owner permission on our queue is going to be set to Consume , so clients modifying topics programmatically is out of question. I was only exploring that as I [wrongly] interpreted withSubscriptions as a way to internally match the messages to receivers based on topic subscriptions. I ran a test similar to yours and realized that’s not the case.
In your example, the queue definition #2 (a durable non-exclusive queue) is what I would be going for, but even with that, there are no guarantees that:
persistent_receiver will receive only messages matching its subscription: topic1/> persistent_receiver2 will receive only messages matching its subscription: topic2/> I was hoping it would work that way so I could have topic-bound receivers, but that’s because I’d wrongly assumed how withSubscriptions would work — any receiver calling withSubscriptions simply registers specified topic subscriptions (if they are permitted to and the subscriptions don’t already exist) on the queue, that’s all. My test proved this as well, so I was wondering if there’s any other way to achieve what I want. Turns out I could use withMessageSelector (in fact, I could have selectors based on the topic value itself as it’s also a property on the message) or one queue for every receiver/handler if I wanted to avoid a central handler with topic-based delegation in the code that badly.