We seem to be having problems with transient JMS messages. We get failures or exceptions, and then restart the server (or just go do some debugging and continue to run it). But sometime later (on the order of minutes), these old messages seems to come back to life. The predefined queues on which the server receives messages are set to the following (on Weblogic 7.0): Enable Store: default (true, false) Bytes Max: -1 Bytes Threshold High: -1 Bytes Threshold Low: -1 Bytes Paging Enabled: default (true, false) Messages Max: -1 Messages Threshold High: -1 Messages Threshold Low: -1 Messages Paging Enabled: default (true, false) Priority Override: -1 Time to Live Override: -1 Time to Deliver Override: -1 Delivery Mode Override: No-Delivery (Persistent, Non-Persistent) Redelivery Delay Override: -1 Redelivery Limit: 3 Error Destination: none
These settings don't seem sufficent. We have redelivery limit set to 3, but the effects we've seen from this are that if the message handling failes, it immediately resends up to 3 times. I'd settle for any way so that when we reboot the WebLogic server, no messages remain in the queues. However, I'd really like a way to programmatically flush out the queues (well, I guess technically, delete, not flush, since I just want to drop those messages). Here's the catch: if possible I would like guaranteed delivery of messages up until we either choose to execute a "flush" or until the server is restarted. (Otherwise I can set everything to non-presistent, right?) Any ideas? --Mark [ March 26, 2003: Message edited by: Mark Herschberg ]
You can always just delete the persistant filestore that WebLogic creates before you start WLS. This will guarantee that there are no messages left in the queue. You could also write a small application that consumes these messages but does nothing with them until the queue is empty. This would effectively purge the queue when it is run.