2008-09-24

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.

No comments: