Hi fea, I would like to point out that there is a section in Qpid broker documentation about non-destructive consumers : http://qpid.apache.org/releases/qpid-broker-j-7.1.3/book/Java-Broker-Concepts-Queues.html#Java-Broker-Concepts-Queue-EnsureNonDestructiveConsumers
You can have a look into following integration test demonstrating how queue with non-destructive consumers works: https://github.com/apache/qpid-broker-j/blob/master/systests/qpid-systests-jms_1.1/src/test/java/org/apache/qpid/systests/jms_1_1/extensions/nondestructiveconsumer/EnsureNondestructiveConsumersTest.java On re-connect, the same messages would be sent again. The resuming of message delivery from the previous point is not supported. As for fanout exchange, it routes messages into all bound queues and exchanges regardless message routing key. I am not sure that you need to use topic exchanges, unless you are after wild-card subscription functionality. Please check the documentation about exchange routing mechanisms at http://qpid.apache.org/releases/qpid-broker-j-7.1.3/book/Java-Broker-Concepts-Exchanges.html#Java-Broker-Concepts-Exchanges-Types If you just need to route message based on routing key, the direct exchange can do that. You can bind topic exchange to fanout exchange and vice versa, but, I am not sure what problem you are trying to solve with that. It does not look like you need it, based on your original problem statement. Message persistence does not depend on exchange or how the message is routed into destination queue. I think that Rob's original advice about having multiple LVQ queues bound to fanout exchange should work for you. Having single non-destructive queue also should work, if your micro-services can handle duplicates (caused by reconnects). Kind Regards, Alex On Wed, 12 Jun 2019 at 10:33, fea17e86 <[email protected]> wrote: > Hi Rob > > Thank you for your quick response. Is there some documentation available > for > "ensureNonDestructiveConsumers"? I couldn't find it in the Broker-J Book. > > The single LVQ sounds like an interesting alternative. Usually there will > be > a database IO, or calculation task run as a consequence of a message. So > starting those tasks over and over again, doesn't seem like a good idea. I > guess the subscribers would have to check themselves which message they > already consumed and which ones they didn't. Or could I solve this issue on > the broker level? I want to keep as much of the message routing logic in > the > broker as possible. > > If I'd use a fannout exchange I would loose the routing behaviour. So > instead of using one, or only a few, topic exchanges, I would have to use > many fannout exchanges, correct? Is any of the two patterns superiour to > the > other? At first glance I do prefer the topic solution. > > What about binding a fannout exchange to a topic exchange, shouldn't that > work? But I would loose the message persistence feature. So only currently > online subscribers would receive the message. Which brings me back to the > LVQs. > > fea > > > > -- > Sent from: > http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
