Thanks for the information, Mark!
We ended up rolling our own redelivery logic similar to your setup.
We have asynchronous listeners which, on recoverable error, create a
copy of the message and place it on a separate redelivery queue. The
message copy has an additional property which spe
Yes. The way we are doing it is adding a bit of metadata into the message to
keep a redelivery count. This is added only when we want to do a
redelivery.
Our framework sits on top of the NMS ActiveMQ provider (.NET). It parses
the metadata from the message. This redelivery logic is abstracted
Hey Mark,
We ended up opting to put the message back on the end of the queue
instead of rolling back, but this leads to repeated reprocessing of
the message. My guess is that you have solved this with metadata:
Our framework is sophisticated enough to
manage redeliveries in this way by ad
We are sort of in the same boat.
Transactions generally are not just used for redelivery purposes. They also
are performance efficient as you can batch.
http://activemq.apache.org/should-i-use-transactions.html
What we are doing to avoid hang ups in clients on redeliveries is to use
ClientAckn
