Redelivery handling in CAPS

At my current client we are still developing integrations on the mighty SUN CAPS platform, former known as SeeBeyond ESB.

The current integration being developed needs redelivery handling controlled by CAPS itself. Frankly it has a nifty feature to setup variable interval using a sting pattern as: count;delay;count:delay;count;delay,.... This is quite nifty as you can use a shorter interval at start and then increase it a bit later. However CAPS doesn't state any upper bounds or the like when setting this pattern. Only at deployment time you get this error:



Not a friendly error message, but hey we do as it said and look into the server log and find the cause (and trust me this time we are in luck as we get a cause):

Caused by: java.lang.Exception: Could not parse [1:5000;10:10000; 100:move(queue:qu3180EUPError)]: error [java.lang.Exception: Delay of
[10000] exceeds maximum of 5000 ms] in element number 1: [10:10000]
at com.stc.jmsjca.core.RedeliveryHandler.parse(RedeliveryHandler.java:536)
at com.stc.jmsjca.core.Activation.activate(Activation.java:203)
at com.stc.jmsjca.core.RAJMSResourceAdapter.endpointActivation(RAJMSResourceAdapter.java:273)
... 107 more
Caused by: java.lang.Exception: Delay of [10000] exceeds maximum of 5000 ms
at com.stc.jmsjca.core.RedeliveryHandler$Delay.(RedeliveryHandler.java:253)
at com.stc.jmsjca.core.RedeliveryHandler.parse(RedeliveryHandler.java:483)
... 109 more
|#]

So basically you can only set a maximum delay of 5 seconds per interval. Well knowing how unreliable the network unfortunately can be, we can have outages lasting for 30+ minutes. or more.

Well at least CAPS supports setting a delay that somehow can be accepted with 5 seconds delay. I wish however I could use 10 seconds or even longer. No there is no exponential backoff setting and upper limit to be used for longer delays.

I am however pleased that we have such features in the Camel.

My next problem was that I wanted the current redelivery count when I was processing the message. However this count is not available to end-users but only to CAPS itself. I can only retrieve information that the current message is a redelivery or not.

Well my next problem is that when a message is then finally moved to the dead letter channel, after X failed attempts I need to alert this. And no the operations staff do not monitor CAPS manually, and any SNMP traps that CAPS could sent is not integrated into the existing surveillance (and I actually don't know if CAPS send a SNMP traps if a message is moved to the dead letter channel) so we are forced to alert by writing to log files ;)

Probably not what SeeBeyond envisioned their flagship product will be used, in such scenarios.

Well low-tech files is still used a lot for integrations and monitoring. So whatever fancy product is out there, don't underestimate supporting low-tech proven technology that regular staff know how to use.

Camel Tutorial - Using Axis with Camel

I have been cranking on some beginner tutorials on using Apache Camel. As of late I was asked how Camel integrates with existing applications using Apache Axis 1.4 as the webservice stack.

Well the question is valid as in my opinion its important for a framework to be versatile, flexible and appeal to the entire community. Apache Camel shouldn't be a high-level framework for geeks only.

So to demonstrate how you step by step can integrate a web application using Axis with Spring and Camel I have created a new tutorial "how to use good old Axis 1.4 with Camel" with an example application that will be distributed with the next release of Apache Camel.

Happy reading. And remember to check out the other tutorials as well.
If you have the time then the report incident tutorial is worth a read.

And if you fancy some more routing and what Camel can bring to the table in that regards, then I suggest you check out Eduard Hildebrandts award winning power point presentation, that is listed in the Articles section.