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 away from the many consumers using our framework and their main logic. It executes a redelivery policy before delegating the work to the consumer to actually process the message. If the redelivery count is exhausted according to the redelivery policy, we simply acknowledge the message without re-cloning, hence redelivering it. As I've been coding it I wonder how necessary it really is to have this functionality though. If you have enough consumers in your cluster it seems the transactional mode would be sufficient. It just so happens our previous messaging framework retried messages by placing them at the end of the queue so this is more of legacy support than anything. Regards Geoffrey Arnold-2 wrote: > > 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 adding some redeliveredCnt >> metadata to >> the message each time it is cloned. > > Can you elaborate? > > Thanks, > Geoff. > > -- View this message in context: http://www.nabble.com/Transactions-and-redelivery-tp25915300p25930878.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.
