I have been banging my head against this for several days. I have a case of durable/retroactive message recovery that is very long and involves a lot of messages. It is done with a custom SubscriptionRecoveryPolicy that gets the messages from a special store. This can involve literally hours worth of message.
This doesn't work well and has different problems depending on the transport. Openwire: Entire operation gets tied up in the act of creating the subscription. Messages aren't delivered at all until the the recovery process finishes pushing old messages into the old subscription. Use of nio doesn't help. Stomp: Broker actually delivers messages to the consumer, at first, but eventually stops because the consumer's acks aren't picked up by the broker and the topic gets 'full'. In fact, no traffic sent by the consumer back to the broker gets recognized at all while in recovery, not event disconnects or connection resets. Messages that get backed up when the subscriber got full only get delivered once the 'recovery' method is done. I need some way to separate the flow of control between the subscription creation, message recovery and consumer communication so that they can all happen concurrently. Any pointers would be greatly appreciated here. -adam -- View this message in context: http://activemq.2283324.n4.nabble.com/Problem-with-long-replay-retroactive-topic-recovery-tp3079446p3079446.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.
