2 Replies Latest reply on Mar 29, 2004 11:09 AM by justbrian

    dlq recovery to single subscriber

    justbrian

      Consider the following situation:

      The topic myTopic has 3 subscribers mdb1, mdb2 and mdb3.

      A message is published to myTopic and mdb1 and mdb2 process the message without error. mdb3 can't connect to the internet (or whatever) and the message is eventually DLQed........

      Now.....it is not a poblem to pull that message off the DLQ and republish it to myTopic at a later time, but when I do this all three subscribers want to consume the message even though mdb1 and mdb2 have already successfully processed it the first time around.

      Is anyone aware of a clean(a relative definition, I know) way to handle this situation that I may(probably) be overlooking?

      Any thoughts would be appreciated.

      Thanks.
      Brian.

        • 1. Re: dlq recovery to single subscriber
          schrouf

          You should better use durable subscriptions and JBossMQ redelivery feature instead of a DLQ. In case of a backend failure for one of your MDB's just call ctx.setRollbackOnly() for mdb-specific rollback of message reception. JBossMQ will automatically redeliver these messages after a configurable ammount of time. Set the redelivery delay to a reasonable time delay ( 1m, 15m, 1h,... ) and set redelivery count to infinite. This effectively disables DQL.

          • 2. Re: dlq recovery to single subscriber
            justbrian

            Hey schrouf,

            Thanks for the response....

            I am using durable subscriptions and have considered cranking up the retries. But, I also like the idea of the DLQ. Monitoring that single queue for problems rather than X number of topics/subscribers.

            I have also been experimenting with using a message selector like:
            (retrysubscriber IS NULL OR retrysubscriber='myDurableSubscriber')
            and populating that retrysubscriber property from information contained in the JBOSS_ORIG_DESTINATION property of the DLQed message when I republish the message.

            This seems to be working well, but it feels kind of hackish. I'm beginning to think that if I care this much about specifying destination in specific situations then I should probably consider using queues for those cases.

            Regardless, at least I have some options...

            Thanks again.
            Brian.