When did Apache Camel First Get Retry Processing?
by
Join the DZone community and get the full member experience.
Join For FreeAnsgar Konermann recently asked me on twitter when Apache Camel first received retry functionality (e.g. a common use-case is to use 'retry' in case of a failure).
So I took a peek at the source code and the commits logs reveals the following
James added support for redelivery on the initial Dead Letter Channel in Camel 1.0. So the answer to this question is that Apache Camel came with this functionality out of the box from the very first release. This just makes the first release even more impressive, than I have previously blogged about.
In Camel 1.1 James improved the error handler to add support for exception clauses (eg the onException) so you have fine grained redelivery policies. For example, you could instruct IOException to have longer and more redelivery attempts, and have your MyBusinessException not redeliver at all.
That came as early as Camel 1.1. Impressive.
We have since improved error handling and retry/redeliver functionality in Camel. For example, you can configure whether Camel should block or use non-blocking while waiting until the next redelivery attempt is triggered.
Another functionality that I remember we (the Camel team) have discussed for a long time how to implement and provide in Camel is graceful shutdown. It turns out it is much easier to startup an application than it is to stop/shutdown the application in a reliable manner.
So I took a stab at implementing this and it was provided in the Camel 2.2 release. That is nearly 3 years ago.
Oh and if you want you can alter the redelivery settings at runtime using JMX, (e.g. to adjust intervals etc.) it can all be adjusted.
@davsclaus since when/which version does Camel support retry processing? Spring Integration added it recently.
So I took a peek at the source code and the commits logs reveals the following
commit d0cba2ad2abda2a4e6a18b29a43f86405452f031
Author: James Strachan
Date: Wed Mar 21 09:56:11 2007 +0000
added an initial implementation of Dead Letter Channel
git-svn-id: https://svn.apache.org/repos/asf/activemq/camel/trunk@520823 13f79535-47bb-0310-9956-ffa450edef68
James added support for redelivery on the initial Dead Letter Channel in Camel 1.0. So the answer to this question is that Apache Camel came with this functionality out of the box from the very first release. This just makes the first release even more impressive, than I have previously blogged about.
In Camel 1.1 James improved the error handler to add support for exception clauses (eg the onException) so you have fine grained redelivery policies. For example, you could instruct IOException to have longer and more redelivery attempts, and have your MyBusinessException not redeliver at all.
That came as early as Camel 1.1. Impressive.
We have since improved error handling and retry/redeliver functionality in Camel. For example, you can configure whether Camel should block or use non-blocking while waiting until the next redelivery attempt is triggered.
Another functionality that I remember we (the Camel team) have discussed for a long time how to implement and provide in Camel is graceful shutdown. It turns out it is much easier to startup an application than it is to stop/shutdown the application in a reliable manner.
So I took a stab at implementing this and it was provided in the Camel 2.2 release. That is nearly 3 years ago.
Author: Claus Ibsen
Date: Sun Dec 20 12:27:04 2009 +0000
CAMEL-1483: Camel now uses graceful shutdown when shutting down.
git-svn-id: https://svn.apache.org/repos/asf/camel/trunk@892587 13f79535-47bb-0310-9956-ffa450edef68
Oh and if you want you can alter the redelivery settings at runtime using JMX, (e.g. to adjust intervals etc.) it can all be adjusted.
Apache Camel
Processing
Published at DZone with permission of Claus Ibsen, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
Trending
-
Demystifying SPF Record Limitations
-
Front-End: Cache Strategies You Should Know
-
Exploring the Capabilities of eBPF
-
Payments Architecture - An Introduction
Comments