How to handle EMS redelivery when exceptions occur in preprocessor
Article ID: KB0072178
Updated On:
| Products | Versions |
|---|---|
| TIBCO BusinessEvents Enterprise Edition | 6.x |
Description
When an exception occurs in an EMS destination's preprocessor, the expectation is that this EMS message should be redelivered according to the settings for this queue. For example:
tcp://localhost:7222> show queue BE.Orders Queue: BE.Orders Type: static Properties: *prefetch=5,maxRedelivery=3,redeliveryDelay=1min,*store=$sys.nonfailsafe JNDI Names: <none> Bridges: <none> Receivers: 0 Pending Msgs: 0, (0 persistent) Delivered Msgs: 0 Pending Msgs Size: 0.0 Kb, (0.0 Kb persistent)
In the above example, the BE.Orders queue is configured to make 3 redelivery attempts, each delayed by 1 minute, if a failure occurs.
However, when an exception occurs in the preprocessor code, messages in the BE.Orders queue may not be redelivered to the running BE application as expected.
Follow the guidance below to handle exceptions properly in your preprocessor code.
Environment
All Supported Platforms
Resolution
Add a catch block to your preprocessor code, and use the Engine.Rtc.abortRTC() catalog function. For example:
This cancels all rule actions scheduled to be executed in the current RTC, and should avoid the issues with EMS redelivery as described above.
body {
int a = 10;
int b = 0;
try {
System.debugOut("result is: "+ a%b);
}
catch (Exception e) {
System.debugOut("***** Exception in preprocessor has occurred (" + e + ").");
Engine.Rtc.abortRTC();
}
}
This cancels all rule actions scheduled to be executed in the current RTC, and should avoid the issues with EMS redelivery as described above.
Issue/Introduction
Describes the bad behavior that can occur if an exception is seen by the preprocessor for an EMS destination, and how to properly handle the exception.
Feedback
Yes
No
Powered by
