JMS Error destination..

Question

Hi,
I am developing a JMS application where i am processing message in a Queue and configured redelivery delay and redelivery limit. When the maximum redelivery limit has reached, i will move the message to an error destination which is again a Queue. I can send an email to the administartor with the message information indicating that the processing for the message has failed. But the requirment is, the administrator wants to view the message from the persistent store and resubmit the message. Is it possible? If that is the case what can be value for time-to-live for the message? I am using ServiceBus 10.3 and using the underlying weblogic server as JMS provider. Besides, i have a question on the relationship between redelivery delay, redelivery limit and time-to-live override. When i tested, if time-to-live is less than the redeliverylimit*redelivery delay, then will the message be deleted and the redelivery limit(number of retries) is not taking into effect. But if time-to-live is greater than also the message is deleted after maximum retry means time-to-live doesn't have effect. This means i am i right to say, if i specify time-to-live and there is no need to specify redeliverylimit and redelivery delay. If that is the case on what basis, the retry is made?
Thanks in advance for your replies,
Sam

Answer 1

Hi,
I am using ServiceBus 10.3 and using the underlying weblogic server as JMS provider. I think OSB tends to decorate JMS messages with its own private information, so I don't know if it can support arbitrarily moving them between destinations. You may be better off posting to an OSB specific forum.
But the requirment is, the administrator wants to view the message from the persistent store and resubmit the message. Is it possible? That said, you can view, delete, move, and file import/export WebLogic JMS messages using the message management screens on the console. If you need a more sophisticated capability than the console provides, it is possible to write Java or WLST program's for the purpose.
If you're interested in scripting, the following might be enough to get you started:
For scripting and tracing examples, see the July 29th and August 10th 2009 newsgroup post with subject "Example using of getMessage(s) with JMS error queues?" [ here | http://forums.oracle.com/forums/thread.jspa?messageID=3657916] and the June 10th 2009 newsgroup post with subject "JMSDestinationRuntimeMBean - possible STATE values " [ here | http://forums.oracle.com/forums/thread.jspa?messageID=3531603 ]. Also take a look at the +Sept 23 2009 newsgroup posts with subject "Enable JMS - Queue/Topic Trace on console"+ [ here | http://forums.oracle.com/forums/thread.jspa?messageID=3782486].
+WARNING: Exporting too many messages at a time can cause out-of-memory errors.+
Besides, i have a question on the relationship between redelivery delay, redelivery limit and time-to-live override. When i tested, if time-to-live is less than the redeliverylimit*redelivery delay, then will the message be deleted and the redelivery limit(number of retries) is not taking into effect. But if time-to-live is greater than also the message is deleted after maximum retry means time-to-live doesn't have effect. This means i am i right to say, if i specify time-to-live and there is no need to specify redeliverylimit and redelivery delay. If that is the case on what basis, the retry is made?By definition, an expired message is automatically deleted -- no matter what the delivery count is. If you want expired messages to be automatically redirected to a destinatin's error destination you can configure an "expiration policy" of "redirect" on the destination.
Whether you want to use message expiration, redelivery limit, or redelivery delay very much depends on your specific use case.
-- Redelivery limits detect messages that are rolled back many times by receiving applications (rollbacks can occur due to any number of reasons, such as database failure, application bug, etc.)
-- Redelivery delays prevent rolled back messages from being immediately redelivered. This helps prevent zooming up CPU usage to 100% with tight loop retries of processing a problem message, assumes that whatever condition caused the original rollback is temporary, and assumes that if the message is immediately redelivered that this is too soon for the problem condition to have cleared up.
-- Expiration detects if a message has been sitting around for a long time. It doesn't detect whether the application has attempted to process the message...
In general, if you are coding a new application, it is sometimes helpful to avoid error destinations. Instead, let your application decide what to do with problem messages (such as queue them to another destination). This helps your application provide more customizable behavior.
Hope this helps,
Tom
PS Especially for developers new to WebLogic JMS, I highly recommend purchasing a copy of the book "Professional Oracle WebLogic". In addition, I recommend reading the new "Best Practices" chapter of the JMS configuration guide, and the new "Tuning Checklist" in the JMS chapter of the Performance and Tuning guide. These new sections are in the 10.3.2 documentation.