Undelivered JMS messages get deleted on startup. Why?

Question

          WebLogic 6.1 (SP2), NT4 (SP6), native IO enabled.
          Here's what happens:
          1. A JMS client posts a number of messages (say 8000) to a Weblogic JMS queue backed
          up by a database store.
          2. The JMS consumer (i.e. Message driven bean's onMessage()) is slow - it has 5 seconds
          of processing to do for each message.
          3.The JMS monitoring screens show 100 messages have been processed - this is ok;
          the client can post much faster than the server can consume. This would imply 7900
          messages undelivered.
          4. We do a controlled shutdown of the server.
          5. A select count(*) from JMS_JMSStore reveals all 8000 messages have been persisted.
          6. We start up the server. The JMS recovery message in weblogic.log indicates that
          a scan of 8000 records has been made.
          7. I would now expect 7900 undelivered messages to be passed to the mdb's onMessage()
          method (remember before shutdown, 100 messages were processed by onMessage()).
          8. This doesn't happen; onMessage() gets nothing, and a select count(*) from JMS_JMSStore
          reveals zero records! Why have these messages been deleted?
          Presumably on startup, the JMS recovery tries to ensure that the JMS store only holds
          messages that have yet to be delivered. But in this case it's deleteing everything.
          Note that there are no error messages or stack traces to report.
          Any ideas, anyone?
          simon.
          

Answer 1

It has to be durable, or there wouldn't be anything in the store.
          What happens if you undeploy and redeploy the MDB (instead of shutting
          down)? Do your messages have a time-to-live? Your configuration has not
          changed? Try it without the MDB. That is just a program that creates
          durable subscriber. Have it receive 100
          messages. Shutdown the server and restart, then restart the durable
          subscriber program. This would prove it is JMS or if the MDB container is
          doing something ugly like an unsubscribe.
          _sjz.
          "DanS" <[email protected]> wrote in message
          news:[email protected]...
          > Simon,
          >
          > The JMS consumer, is it created as a durable subscriber? As far as I knoe,
          > weblogic will keep the messages in the queue / topic only if the consumer
          is
          > registered as a durable subscriber.
          >
          > Dan
          >
          > "Simon Spruzen" <[email protected]> wrote in message
          > news:[email protected]...
          > >
          > > WebLogic 6.1 (SP2), NT4 (SP6), native IO enabled.
          > >
          > > Here's what happens:
          > >
          > > 1. A JMS client posts a number of messages (say 8000) to a Weblogic JMS
          > queue backed
          > > up by a database store.
          > >
          > > 2. The JMS consumer (i.e. Message driven bean's onMessage()) is slow -
          it
          > has 5 seconds
          > > of processing to do for each message.
          > >
          > > 3.The JMS monitoring screens show 100 messages have been processed -
          this
          > is ok;
          > > the client can post much faster than the server can consume. This would
          > imply 7900
          > > messages undelivered.
          > >
          > > 4. We do a controlled shutdown of the server.
          > >
          > > 5. A select count(*) from JMS_JMSStore reveals all 8000 messages have
          been
          > persisted.
          > >
          > > 6. We start up the server. The JMS recovery message in weblogic.log
          > indicates that
          > > a scan of 8000 records has been made.
          > >
          > > 7. I would now expect 7900 undelivered messages to be passed to the
          mdb's
          > onMessage()
          > > method (remember before shutdown, 100 messages were processed by
          > onMessage()).
          > >
          > > 8. This doesn't happen; onMessage() gets nothing, and a select count(*)
          > from JMS_JMSStore
          > > reveals zero records! Why have these messages been deleted?
          > >
          > > Presumably on startup, the JMS recovery tries to ensure that the JMS
          store
          > only holds
          > > messages that have yet to be delivered. But in this case it's deleteing
          > everything.
          > >
          > > Note that there are no error messages or stack traces to report.
          > >
          > > Any ideas, anyone?
          > >
          > > simon.
          > >
          >
          >