X-mas present to Apache Camel - Graceful Shutdown

I am currently on x-mas holiday and enjoy the time with family and friends. However I am also a man with obligations as I am a co-author on the Camel in Action book. My next chapter is chapter 11 which covers management and monitoring Camel.

You can say that my research for that chapter took my round the areas of how to manage Camel and therefore also how to properly operate it for example in cases where you need to restart Camel. To restart you need to stop Camel, and to stop in a safe manner you need to graceful stop. Yeah now we get to the point of this blog title.

So besides working for Progress, writing on the book and the usual x-mas last minute must buy gifts, I have been working on adding graceful shutdown for Apache Camel. As of today I have committed the last pieces of the puzzle. So from Apache Camel 2.2 onwards we got Graceful shutdown supported in Camel. It follows the principle with Camel, that everything is more or less pluggable and configurable as much as possible. This gives you full powers at your fingertips to tweak and configure it to tailor your needs. And in some rare cases you can just plugin you own graceful shutdown strategy and deal with it.

Oh and its enabled by default so you get it right out of the box. You can checkout the Camel documentation for details and screenshots - cough well its some log lines showing it in action.

As James Strachan pointed out, its book driven development :) Yeah I must admit that during our work on the book we have encountered some areas to be improved, new features to be introduced etc. So its a win win situation.

We do have an ongoing discussion on the graceful shutdown which you can read about and provide feedback etc. The JIRA ticket is CAMEL-1483. Which is a somewhat older ticket. And readers of my blog my remember that I wrote on the Camel 2.1 announcement that graceful shutdown is a high priority feature to get in 2.2.

So what is next? Well chapter 11 and better thread pool configuration :)

Have a merry x-mas and a happy new year. See you in 2010.

Camel community strikes again - Two new components contributed to Apache

The binaries from last 2.1 release has just landed on the various mirrors sites and we already got great stuff coming in the next 2.2 release.

Christian Mueller have recently contributed two new components to Apache Camel they are using in production at his company. This is fantastic as they are production proven components. Thanks a lot.

Christian contributed the FTPS (FTP over SSL) component which now brings the FTP to a total of three variations: regular FTP, SFTP (FTP over SSH) and the new FTPS (FTP over SSL). That is fantastic as if you want FTP then we got all those variations out of the box.

Christian also contributed camel-smpp which integrates Camel with Short Message Center to send and receive SMS. That is fantastic timing as others in the community is on lookout for such a component.

Christian and others keep up to great work. This is another testimony that Camel is all about community and love contributions. Without all these great contributions over the time, Camel wouldn't have the impressive list of components , languages and data formats we do today.

Apache Camel 2.1 released

Its great news that Apache Camel 2.1 is now GA and thus when we come back at work monday morning the Apache mirrors and maven repos have synced the binaries.

As Hadrian wrote in the announcement on the Camel front page its a big release with a record high of 303 tickets resolved.

Hadrian also highlights some new features and whatnot, and I would like to add to that (in no particular order):

• Vastly improved startup, where Camel validates for correctness upfront and in case of problems a better error is reported back with details in which and where in the route something is wrong
• You can control startup order of routes, and whether a route should be auto started or not
• Fixed some race conditions on shutdown which otherwise would make Camel appear as hung
• Vastly improved bean component to better pick correct method and/or fail
• Improved error handling with better onException being triggered
• File and FTP components is more fault tolerant and have build in workarounds for Windows issues with file system
• XPath is faster on high concurrent load, greatly reduced contention
• Added Exchange.FAILURE_ENDPOINT when sending to an endpoint failed, which allows you to use that information in your error handling
• Added in flight repository which is a great step for supporting graceful shutdown
• and much more... 

Camel 2.2 is already underway and I think we have about 15 tickets fixed already. My next target for work in 2.2 is to add support for graceful shutdown which should allow you to safely stop Camel without loosing messages. In Camel 2.1 you can use JMX to stop Camel and keep an eye on the in flight registry and if its at 0 then you can stop Camel. You can use JMX to stop routes beforehand so no new messages comes in. So we got all the pieces now, its just a matter of letting Camel figure this out on its own, and with the help from the startup order you can aid Camel in some of the very rare situations where route Y must be stopped before route X etc.

Another area I would love to give some love is thread pool configuration which now is possible, but Camel should have a nice and slick configuration for that. If you got any ideas and requirements for this I would love to hear them.

Okay its friday and the World Cup draft is on now. Take care.

Camel in Action - New chapters in MEAP and special discount code

As Jonathan already have announced there are two new chapters available for the Camel in Action book.

I will quote from Jonathan what chapter 2 covers:

Chapter 2 is basically all about routing - a pretty fundamental topic for Camel! I cover route creation in Java and Spring, as well as several EIPs. Since it is such an early chapter its pretty hand-holding throughout - you don't need to know Spring or EIPs beforehand, for instance. 

The other new chapter is chapter 4 (Yes we have rearranged the chapters a bit.). It covers how to use beans with Camel. You may think there isn't material to mandate a topic about beans? Well Camel does go through great lengths to ensure using beans is easy and painless. But under the covers a lot is happening and this chapter discloses what and how. We wrote the code so we damn well talk about how it works :). The goal is to help you better understand and leverage the many features Camel provides for using beans. Camel has clever parameter binding which allows you to have loose coupling between Camel and your beans. It also have a arsenal of parameter and method annotations which has its merits as well. The chapter is also written in a more engaging style allowing you to try out and test as we goes. 


Beware Manning have not yet updated the table of contents in the book website. I assume they will do this later today to reflect the latest rearrangement.


We are also happy to announce that Manning have provided us with a special discount code for this MEAP update. You can get 30% discount for any of the Camel in Action versions (ebook, print book or combo). Use checkout code camel30 from the Camel in Action website.


As always we love feedback and suggestions on the book forum.

Apache Camel - Yet another contribution added to Camel

Stephen Gargan decided to contribute an useful extension to Camel he had done. He created a JIRA ticket CAMEL-2206 and attached patches.

He have created a new EIP called Sampling which allows you to sample a Message during a period. For example suppose you receive a lot of noisy messages and you just need one sample. This is what this pattern does. Note the Aggregator EIP could also do this but it would be a bit more complex to setup using correlation expression and aggregation strategy and whatnot. With the sampler its a dedicated throttler to sample one message out of many.

This morning I reviewed his latest patch and decided it was great quality and spent the time it took to get it into camel-core.

I also wrote initial documentation for it.

Stephens contribution is just one of many for Camel. In Camel 2.1 we already have 5 new components by which I believe 3 of them are contributed from the community, 1 from our new committer Martin Krasser and the last from my employer Progress.

And top that with all the great feedback we get on the mailinglist, irc chat and JIRA tickets by which some have patches. Also thanks to all the people who engage and help test issues based on SNAPSHOT builds. Without you the Camel community was not what it is today. Keep up the good work.

Apache Camel 2.1 - Update on releaseplan

Its almost 3 months since Apache Camel 2.0 was released so its definitely time for a new release and that is why Apache Camel 2.1 is now feature complete. At this time of writing we are waiting for a couple of SNAPSHOT dependencies to be released over at our friends from Apache ServiceMix.

So hopefully in mid next week Hadrian will be able to start building the release kit for Apache Camel 2.1. However before that happens the Apache Camel 1.6.2 release should have gone GA. The vote is still in progress but so far only +1 votes. Assuming everything runs by the book then we will have a release kit at the end of next week which goes through the voting process at Apache. If all again is well then 2.1 will be GA early December. Maybe a bit faster depending on how well it goes for Hadrian to build the release kits.

When Apache Camel 2.1 is GA it will also be included out of the box in the upcoming Apache ServiceMix 4.1. So our friends at SerivceMix is also eagerly waiting for the Camel.

If you want to take a look whats included in Apache Camel 2.1 then checkout the release notes which we write during development.

Camel 2.1 - RoutePolicy a new feature

Apache Camel 2.1 is coming along really nice. Just got one of the last features in today, but that feature is for another blog post.

In Camel 2.1 we have introduced the notion of a route policy. It is used for controlling routes at runtime in a dynamic fashion. You assign a route policy to one or multiple routes which then at runtime will invoke a callback on the RoutePolicy interface. This interface provides hook to control the route such as suspending or resuming it. However you can implement the logic of choice.

By default we ship with a ThrottlingInflightRoutePolicy which is a dynamic throttler based on the current number of inflight exchanges. So you can configure it to throttle at thresholds such at 500 in flight exchanges and a low water mark at 40% etc.

To see all this in action we have added a new Route Throttling Example you can try out and learn how to use this in your projects.

And the ThrottlingInflightRoutePolicy is also JMX enabled so you can change its thresholds at runtime as well. Talk about dynamic :)

There are much more details on those links in this blog. And I have to advert for my book - Camel in Action, where we will provide more details of this feature.

How well does your integration stack respond to your tickets

This blog title could easily be the 2nd part in a blog series. However it is not. Just wanted to a catchy title :) But it would be interesting to check upon the state in the JIRA on terms of responsiveness. However I leave that up for others or I may take a look at this sometime in the future.

What I want to tell is that this morning I did my usual habits and thus also checked upon the Apache Camel JIRA tickets.

This morning Jörn Kottmann reported that setting the timeout on the FTPClient was not possible in ticket CAMEL-2160.

I checked upon this and agreed that it should be easier to configure in Camel and thus began improving this. About 2 hours later I committed to changes and updated the wiki page as well.

The ticket was reported 2 hours before I started working on it, so in total the ticket was open for about 4 hours.

This is a good example how well we often respond to peoples tickets in the Camel community.

I am sure we have similar examples in the past as well, this is not a isolated case.

So how well does your integration stack respond to your tickets? At Camel we strive to respond and in timely manner.

I challenge you to find a ticket which has not been touched at all in the Camel JIRA tracker.

How buggy is your integration stack?

This morning I had another blog topic planned but as usually I start by a cup of coffee and check the news, mails and tweets.

I thought Dan Kulp's blog post, How buggy is your SOAP stack was really good. It inspired me to check upon the situation with Apache Camel. I recommend reading his blog entry first before reading mine.

I will keep the investigations on Camel solely as people can do their own investigation on other integration projects.

As of this morning, november the 5th 2009 these are the numbers from Apache Camel JIRA:

• 2139 tickets in total
• 159 outstanding tickets (7% of total)

And looking at the 159 outstanding we have:

• 147 improvements, new features, etc. (all except bugs)
• 12 bugs

So in total we have reported at total of 12 bugs in Camel out of 159 outstanding issues. That is yet again around 7-8% of the outstanding tickets which is a bug.

Lets go over those 12 bugs and check what they cover

CAMEL-1769: It boils down to the Camel web console when it shows the routes rendered in Groovy it has trouble rendering complex expressions. This is not a bug which affects runtime as the groovy render is used to view the routes.

CAMEL-1788: Flatpack does not work with OSGi. Really not a Camel bug. The flatpack library is rather old and not OSGi ready. Loading its resource file on the classpath does not work well in OSGi land. The reported have reported this to the Flatpack issue tracker. We could in fact close this as its not a problem in Camel.

CAMEL-1974: Charles Moulliards excellent OSGi tutorial had some cosmetic typos and it could benefit to upgrade to latest Karaf standard. He is currently working on this.

CAMEL-1893: The camel-cxf code appears to under a rare situation to set the HTTP status code twice using different case. William Tam have been assigned this ticket.

CAMEL-1898: Hadrian is looking into the build process having a problem with generating the pdf manual during this process. It can however be generated manually thereafter.

CAMEL-1913: camel-jetty and multipart data. This is kinda an improvement.

CAMEL-1941: The tracer does not trace doTry .. doCatch .. doFinally correctly. This only affects diagnostics trace logging. Routing your messages using doTry ... et all works fine.

CAMEL-2001: Relates to the transactedInOut option on the camel-jms component. Its a bit confusing what its useable for. We are discussing this on the mailinglist whether to remove this option. And/or improve the wiki documentation about it.

CAMEL-2021: Guillaume Nodet is working on improving OSGi in Camel. Currently there is an issue with mixed versions running in Karaf.

CAMEL-2059: Relates to its not too easy to do custom error handling with transacted routes. I will look into this when I start writing the transaction chapter in my book. Which is in fact the next chapter I will write.

CAMEL-2129: camel-cxf has an misleading exception message when a call times out. Willem Jiang and Christian Schneider have already fixed this. Code is committed. So this ticket will be closed when Willem does this later today.

CAMEL-2137: Reported yesterday. Related to using Camel in ServiceMix 3.x with JBI.

Notice that the bugs listed here are all fairly new. CAMEL-1769 is created on june 28th 2009.

As of today there has been 698 bugs reported to Camel and of which only 12 is open, that is less than 2% open of all reported bugs.

We have rigorous many unit tests in Camel 2.x at this time we have > 4000 unit tests. That also helps keeps the bug count low.

Then we have a couple of discussions going on the mailinglist which may be a bug in Camel. Lets go over the ones I can remember working with recently.

1) Camel Mail issue with unsupported charset by dcheckoway

This is an end user who consumes mail from a mail server which contains a mail that is using a weird charset which is not supported in the JDK itself. We are working with him to add a feature that tries to change the mail message to remove that charset to see if we can then have the SUN Mail API process the mail.

2) JMS Transactions and RequestReply - transactedInOut=true not working? by jonathanq

See CAMEL-2001 above

3) Problem of skipped items/stories in Camel RSS reader by Cliff Court

An end user is using camel-rss to read some feeds and it appears to skip some feeds. We wonder what the issue is whether its the ROME framework that does the actual RSS work.

4) Error handling with recipientList by mcrive

This is an end user using Camel 2.0.0 who wants to do custom error handling and have precisely information which endpoint failed in case of an error. This feature is already implemented out of the box in 2.1. But the end user wants to use 2.0.0. Have advised him a solution that could work in 2.0 which by adding unit tests also proves. However on his end there is still an issue when its the FTP endpoint that fails. Unit tests in Camel itself shows that it works.

There may be a couple of more issues ongoing on the mailinglist. But the end users haven't reported back etc.

I think the state in Camel is excellent.

I end this blog by answering the blog title:

How buggy is your integration stack? Camel its not buggy.

Getting started with Apache Camel webinar part 2

This is a blot post on the 2nd part of a webinar series about getting started with Apache Camel.

If you missed the first part then I recommend checking this blog post first.

Scott Cranton, Progress, continues in this 2nd part of the webinar by looking at the different deployment options using Apache Camel.

He shows among others the following different deployment options:

• Standalone Java Application
• Web Application
• Spring Application
• ActiveMQ
• OSGi in Apache Karaf / Apache ServiceMix

The webinar is listed at the webinar page at http://fusesource.com under webinars.

And its titled - Getting Started with Camel deployments.

During the presentation Scott talks about how Camel compares to other integration products. He mention a link on my blog, which is this one.

And may I add that I personally think its very important, when you compare/investigate products, that you spend equally time looking at the community surrounding the products. As as we say at Apache - Community over Code! I talk about this in more details at my interview at dzone a while back. Another source worth checking out is the links to articles at the Camel site.

Well go grab a big cup of coffee and get ready and watch Scott in action with the 2nd part.

Camel in Action - Straight to the top of the Manning bestselling chart

Manning recently published Camel in Action available from their MEAP program.

Now a week later they published the updated list of the bestsellers, and yes Camel in Action tops that list. That is fantastic response from the community that there is indeed a demand for such a type of book. For us the authors its a tremendous boost in morale and makes the hard and late hours writing more enjoyable.

This blog entry is also a kind a reminder for myself in the future that I had a book on the top of a chart.

I guess by next week the chart has another book on the top, and who knows if Camel in Action is even in the top 10.

Announcing Camel in Action

It seems like a long time since Hadrian got the ball rolling which I am now happy to be able to announce officially.

Apache Camel is another great project which takes the next step and has a book being published.

That is why I am proud to part of that with my two co authors: Hadrian and Jonathan Anstey. We are writing the book title - Camel in Action, to be published by Manning. Yes its another great book in the action series.

Today the book gone MEAP which means the first 4 chapters is available online. You can read more at Manning what MEAP is. But in terms of Camel you should know that a lot of great documentation and material on Camel itself will go into that book.

For example if you are looking for how to test with Camel, then we got chapter 5 which has 30+ pages on this subject. Actually chapter 5 is online right now.

Since the chapters are not officially finished yet, you can read then in draft form and be able to provide feedback and help influence the book as well. Please use the manning author online forum for this.

Me personally is currently busy writing yet another chapter which is chapter 7 on using beans with Camel.

Apache Camel alternatives

Just wanted to let you know that Gunnar Hillert wrote a nice blog entry with a brief overview of other projects in the integration space.

Take a look at his blog at Apache Camel alternatives.

Getting started with Apache Camel webinar

This morning I did brew a kettle of coffee and had a danish (hint: its bread) ready for breakfast.

Then I fired up Firefox and hit this url which have a new webinar listed - Getting started with Camel: FUSE Mediation Router. You find the webinar under the archived section.

A colleague of mine Scott Cranton (Progress Software) does a great presentation in about 90 minutes. He does a fantastic introduction what Camel is, and explains it really well with diagrams and an example we all can relate to. If you are new to Camel or have the 15 minutes he used to cover this I encourage you to take a look. After all you have to do is to have a cup of coffee ready and then sit back and view and listen.

Then he goes on with live demos where he shows how to use Camel to solve real problems that he have encountered at FUSE customers. He does all that from inside Eclipse so you are going to see live code and how Camel works well in Eclipse as developer environment.

At the end there are questions from the audience which may give answers to some of your questions as well.

Scott mention that there is a 2nd webinar on the road. Yes its the next logical step where Dan Van Santeen shows how to deploy and run Camel in other containers such as Apache ServiceMix etc. The link for this webinar is here.

PS: Using Safari the webinar did not output sound, so I switched to use FireFox and it worked.

Apache Camel 2.1 - Improved startup

Apache Camel 2.1 is coming along real nice. After the big overhaul of the management I have turned my attention to make Camel more robust on startup and shutdown.

First of all Camel now waits to start the input consumers for all routes until last. What it means is that Camel will prepare all routes beforehand by starting all its services. Then at the very end Camel will open the gates to Camel by starting all the route inputs in one go. This helps the situations where you before could end up having a consumer started which then would pickup messages and route them lets say to another route which was not ready. Now all this is gone.

On top of that we have added two more features to routes as well. You can now control:

- whether a route should be auto started or not

- the order in which routes are started

The former can be used if you have some special routes you want to start manually on demand etc.

The latter helps Camel starting the routes in correct order as well when stopping the routes again when shutting down. The idea is that you assign an unique number to the route that dictates the order, just as you can do with Servlets.

See more details in the Camel documentation.

And btw we also fixed a race condition when Camel was shutting down and you used JMS consumers. It could in some cases make Camel appearing as hanging. Now Camel should be able to shutdown properly when using JMS consumers.

Got five minutes and want to learn about Apache Camel

I have been impressed by Gunnar Hillert who created a nice blog series about Apache Camel. He really hits the nail with his short and precise blog posts. At this time of writing he have two blog posts in his series. Hopefully he writes more.

If you are curious about Apache Camel then I recommend to take the five minutes it takes to read his blogs. And on the 2nd blog there is real code :)

Go read mere here Camellos - Discovering Apache Camel. And make sure to read both blog posts in the series.

Overhaul of management of Apache Camel

For the past 3 weeks or more I have been working hard on giving an overhaul of the management of Apache Camel. This works is starting to shape up really well, so I thought I wanted to share this in a blog.

We knew that in Apache Camel 1.x the management using JMX was a bit limited and therefore promised that we would address this in Camel 2.1.

A breakdown of the noteworthy improvements and new features are:

• Pluggable management API to allow 3rd part to fully integrate their own management of Camel
• Introduced event notifications targeted at operations staff
• Overhaul of exiting mbeans and added many new mbeans types
• Full lifecycle support to start/stop camel, routes, consumers, producers, services etc.
• Many more attributes visible such as: State, Route Ids, Endpoint Uris so you can pin point the mbean where it belongs
• More statistics gathered
• Tracer can be fully managed for example to enable/disable tracing on a particular route to help understand how messages are routed at runtime
• Route statistics is now accurate :)
• Error handlers is now fully managed as well, for example to change redelivery policies at runtime
• JMS is fully manageable so you at runtime for example can change number of concurrent consumers
• Certain EIP are manageable as well such as Throttler, Delayer, WireTap, etc. More to be added in the future.
• Easier to let custom Camel components be managed as well by implementing ManagementAware SPI interface
• Component specific management such as JMS, Timer, Scheduled Poller (File, FTP, Mail, and others). And many more to come.
• Pluggable naming strategy in case you want to register the mbean using a different naming convention
• Granularity of performance statistics can be preset on startup to either: All, RoutesOnly or Off. At runtime you can turn it on/off at each mbean that supports statistics.
• And more I may have forgotten

The following lists the different mbean types currently being registered for management at runtime

• CamelContext
• Components
• Endpoints
• Routes
• Consumers
• Producers
• Processors
• ErrorHandlers
• Tracer
• ... and maybe more to come

On top of that we have added a new management example that demonstrates this improved management of Camel. You can then play with the example to change configuration at runtime to e.g. try to improve the overall throughput of the messages being routed in the example.

What we also will do in the future is to add continue to add component specific management such as we already have done for JMS, Timer and the scheduled pollers such as file and ftp. For example we got camel-quartz on the radar so you can change it as well at runtime.

All you need to do is to implement the ManagementAware interface and then Camel knows its has custom management instead of using the default it would have used otherwise. Then you would as often decorate the component endpoint, consumer, producer etc. with the spring @ManagedXXX annotations to expose the attributes and operations. That is all there is to it. And if you want to contribute to Camel then grab a component of choice and help us with a patch.

This is also an announcement to give you the chance and time to try out the new management in the upcoming Apache Camel 2.1. And please any feedback is much welcome. Its better that we get it while we are working on it than after the release.

I suggest that you start with reading about the new management example and go download a SNAPSHOT build and try it out.

Feedback can be posted on the Camel mailinglist or on this blog.

Apache Camel 2.0 released

I am proud that we made it so far today and can announce Apache Camel 2.0 has been released.

This is quoted from the news item

The Camel riders are pleased to introduce the Apache Camel 2.0.0 Release. This is a major overhaul of Camel that took more than a year of efforts and is coming with about 760 issues resolved. We are grateful to the entire community for its involvement. Your hard work and constant attention to details promoted Apache Camel to wider adoption and leadership position in the integration space.

The feature and improvements list is too large to fit here, so please check out the release notes. Note that along with many improvements came a few api changes and migration from the 1.x line, while not too complicated, is not straightforward. The old Camel 1.x branch will still be supported for a while although the upgrade to this hot release is strongly encouraged.

Many thanks to all the contributors who made this release possible. Download Camel now and enjoy the ride!

The Camel Riders

At FUSE we have scheduled to release our version of Camel 2.0, the FUSE Mediation Router 2.0, next month. In addition to the Apache Camel version we will among others include much improved management capabilities in our release.

Quick update on Apache Camel 2.0 release

We had a few setbacks with the build of the release candidate for Apache Camel 2.0.

Hadrian have been working hard to get it resolved and encountered different issues whenever he got one obstacle resolved.

However as this time of writing the release build is in progress and it looks good.

You may wonder why these issues? Yeah it was a few factors such as an Apache infrastructure upgrade causing weird issues with documentation generation and whatnot.

And Maven itself had some issues :) It is fantastic how brittle it becomes, but there are also a ton of various plugins needed for doing a release.

However if all goes well the RC is published today/tomorrow and the Apache voting produce can start.

And if all goes well then it should be out by next week, or at the latest start of next month if any blocker is found in the release candidate.

Identifying bottlenecks with YourKit

First of all I would like to thanks on behalf of the Apache Camel committers, Anton Katilin from YourKit as he was so kind to donate OS licenses to their excellent profiler.

It comes handy as we have planned to look performance tuning Apache Camel 2.0.x.

However it was actually in another matter YourKit proved itself. The FUSE team had identified a performance bottleneck in Camel 1.6.0 in a special situation when using the recipient list EIP together with a simple expression that where using headers with the Integer type. That special cocktail degraded the performance. With the aid of YourKit and digging into the open source code at Apache Camel I was able to identify the bug within the hour.

And YourKit could even help pin pointing that when the recipient list only contains one destination we could avoid using java.util.Scanner as it had an impact on the performance as well.

Working together with the FUSE team quickly resolved the issue and we could reassure the customer with a workaround and that the problem is fixed in the next release. Thanks to our dedicated team of on site consultants we can react quickly and ensure high quality when Camel is used in enterprise scales as this particular customer is.

Well this blog is a praise for YourKit. Installing it is only a breeze on the Mac OS as its just the usual download and drag to applications. And when its starting it can integrate to IDE. That allows me to just start IDEA and find an unit test and click the profile button, thats it!

Then I can browse the YourKit application and see all kinds of stats. It got a "hot spot" button to help quickly pin point quick wins as well.

We have setup a wiki page for the Camel 2.0.x performance tuning experiments. So if you have ideas or want to help out take a look. We got a branch in SVN with the actual code experiments we are doing - and yes we use YourKit to help us.

Apache Camel 2.0m3 released

The 3rd milestone release of Apache Camel have just been released - Apache Camel 2.0m3.

What at first seemed like a quicker release of Apache Camel 2.0 in the start of 2009 have been postponed to a late summer 2009 release instead.

We decided to go for a longer release to do even more API cleanup to pave the road for a solid 2.x foundation, as we are not keen on starting another major 3.0 release this year that would be required if we needed to work on the API yet again.

This time the foundation is nearly settled as we are in a position where we can do internal improvements without affecting end users at all or 3rd party component builders. For instance we have lined up ideas for performance improvements in Camel 2.x, that would not have been possible if we did not undertake the extra work we did in this 3rd milestone release.

There are one more task left before we can do a Camel 2.0 release. We would like to do a few minor modifications to the Exchange API both externally and internally. The goal is to improve both ease of use and laying the last brick in the 2.0 wall.

The release notes of 2.0 m3 highlights the most noticeable changes and new features.

You can grab the release from the download page and/or from the central maven repos.

On the road to Camel 2.0 - OnCompletion

Its time to write a new blog entry on another new feature in Apache Camel 2.0 - on completion.

On completion allows you to do additional routing when an exchange has been completed.

Imagine you need to register a special log entry when a particular route is complete. What you could do at first sight was just to add a processor at the end of the route that would log the entry.

But now the processor is part of the original route and it could potential affect the outcome. For instance lets say the processor could not log the entry and fails, or it accidently changed or altered the payload, or it was time consuming. All affecting the original route.

So how can we avoid this? What we want to do is to execute our processor after the original route is complete. With the new onCompletion DSL you can do this.

Lets look at a little sample to help understand how its setup and works.

First we define a route as below:

from("file://inbox")

.to("bean:validateFile")

.to("activemq:queue:inbox");

And then we want to do run our custom processor FileCompletionProcessor when the route is complete. So what we do is to register an onCompletion on this route.

This is done by adding our onCompletion

.onCompletion()

.process(new FileCompletionProcessor())

.end()

... to the route as shown below:

from("file://inbox")

.onCompletion()

.process(new FileCompletionProcessor())

.end()

.to("bean:validateFile")

.to("activemq:queue:inbox");

Notice: We need to declare an end() on the onCompletion route to indicate the end of this one. What it means is that the onCompletion is a first class route on its own. So you can do all the DSL in this route as you like. You can do content based routing, filtering, invoking additional processors or beans etc. For Camel its just another route.

What happens is that when the original route is complete, e.g. the file content have been send to the activemq queue and the route is complete. Then the onCompletion kicks in. What Camel does internally is that it starts a new route in another thread that has a copy of the original exchange, that is routed in the onCompletion route. So the original route continues to run in its own thread to complete immediately. This ensures that the onCompletion route will not affect the original route.

The sample above was a basic example. What if you only want to do special work in case the original route failed? Well Camel supports DSL to specify:

- onFailureOnly

- onCompleOnly

For instance we want to invoke a bean registered with the id failureService in case the route failed. We can do this as:

.onCompletion().onFailureOnly()

.beanRef("failureService", "fileFailed")

.end()

And just like other functions in Camel onCompletion also supports scopes:

- global

- route

And the onWhen predicate that you might have seen as well.

Take a look at the documentation for further details and sample. It provides XML samples as well.

Apache Camel 2.0m2 released

Yeah finally we got the 2nd and last milestone for Apache Camel 2 released.

And this time even the front page at Apache Camel has the news item in time :)

I had used 30 minutes to write a nice summary of the important new features in this release. But somehow Blogger managed to shrew things up so it got lost. Damn why does it not auto save and let you look back revisions of edits. What I could get back was just the first 2 lines. So I am not in the mood to rewrite it again, so I keep this blog post short.

You can check out from the release notes here.

This is the last planned milestone release. The plan is to use close in on the final release, fixing bugs and adding a few new features. And maybe taper a little with the API as we can seize the moment and do it before 2.0 is out. We hope to get 2.0 out within 1 month.

Please give 2.0m2 a test drive and we are especially interested in hearing about your experience if you upgrade from existing Camel 1.x applications.

Need tooling for Camel? We got FUSE tooling

At FUSE we do have tooling for Apache Camel. In fact the new FUSE Integration Designer 1.2 release is out of the door.

This tool have visual route editing for Apache Camel. My fellow colleague Oisin Hurley, whom is the leader on FUSE tooling announced it on his blog.

What is especially interesting for Camel in this release is that they have added all the EIP patterns we have in Camel. And its really cool to finally be able to see the routes in great looking diagrams. Its like being able to see the Matrix code as motion picture instead of green scrolling text.

Its a two way editor so you can import existing Camel routes, continue to edit them and export it back. And yes you can also export the diagrams as image files so you can put them in word documents or the likes.

You can read more about the FUSE Integration Designer and downloads at this link.

And head over to the FUSE Tooling forum where you can ask questions about the tooling and even meet Oisin himself on the forum.

On the road to Camel 2.0 - Concurrency with the async DSL

Its time to continue the road to Camel 2.0 and I thought that I should detail a bit more on the async DSL we have in Camel 2.0. It replaces the old thread DSL from Camel 1.x.

The async DSL is like the thread DSL used for concurrency. Under the async DSL lies the excellent Java Concurrency API where we leverage the ExecutorService for submitting concurrent tasks.  By default a thread pool with 5 threads is created. But you can pass in the core pool size if you like. For instance: from(x).async(20).to(y)

Suppose we have this simple route where we poll a folder for new files, process the files and afterwards move the files to a backup folder when complete.

from("file://inbox?move=../backup-${date:now:yyyyMMdd}")

    .to("bean:calculateBean");

The route is synchronous and there is only a single consumer running at any given time. This scenario is well known and it doesn't affect thread safety as we only have one active thread involved at any given time.

Now imagine that the inbox folder is filled with filers quicker than we can process. So we want to speed up this process. How can we do this?

Well we could try adding a 2nd route with the same route path. Well that doesn't work so well as we have competing consumers for the same files. That requires however that we use file locking so we wont have two consumers compete for the same file. By default Camel support this with its file locking option on the file component. But what if the component doesn't support this, or its not possible to add a 2nd consumer for the same endpoint? And yes its a bit of a hack and the route logic code is duplicated. And what if we need more, then we need to add a 3rd, a 4th and so on.

What if the processing of the file itself is the bottleneck? That is the calculateBean is slow. So how can we process messages with this bean concurrently?

Yeah we can use the async DSL, so if we insert it in the route we get:

from("file://inbox?move=../backup-${date:now:yyyyMMdd}")

    .async(10)

    .to("bean:calculateBean");

So by inserting async(10) we have instructed Camel that from this point forward in the route it should use a thread pool with up till 10 concurrent threads. So when the file consumer delivers a message to the async, then the async take it from there and the file consumer can return and continue to poll the next file. By leveraging this fact we can still use a single file consumer to poll new files. And polling a directory to just grab the file handle is very fast. And we wont have problem with file locking, sorting, filtering and whatnot. And at the same time we can leverage the fact that we can process the file messages concurrently by the calculate bean.

Here at the end lets take a closer look what happens with the synchronous thread and the asynchronous thread. The synchronous thread hands over the exchange to the new async thread and as such the synchronous thread completes. The asynchronous thread is then routing and processing the message. And when this thread finishes it will take care of the file completion strategy to move the file into the backup folder. This is an important note, that the on completion is done by the async thread. This ensures the file is not moved before the file is processed successfully. Suppose the calculate bean could not process one of the files. If it was the sync thread that should do the on completion strategy then the file would have been moved to early into the backup folder. By handing over this to the async thread we do it after we have processed the message completely.

For more information about the new Async API in Camel check out my previous blog entry and the Camel documentation.

Update: async was renamed to threads in Camel 2.0 final.

Those where the days where the internet led did not go green

Monday night a storm hit southern Sweden and as the blog title indicates the storm did bring in other issues than just rain and thunders. Next morning the internet connection led did not go green and thus not much you can do. The enjoyment of having the first cup of coffee isn't quite the same as you cant take it easy and read the news on the net and turn to your mail box to see how many millions I have won in all the lotteries or what's the spam of today is.

 

As I get up before most of other people I had to wait until 8 am before my ISP provider opens the support center. Well you still get a voice machine.

In the old days you used to navigate these call centers by pressing the numbers on the phone. But not today they use voice recognition. So as a Danish citizen living and working in Sweden its a challenge to understandable swedish for a voice machine to understand that I just want to get a status when the internet will be back. After several tries and having a lot of "I don't understand you" from the voice lady, I won, it gave up and presented me the good old fashioned button menu navigation. With this I could press 4 and then 3 and get the status. And guess what, the next time I call in its much faster with the button navigation as I could just press 4 and 3 again. But no the damn phone company want to pesky me with that voice lady again. 

As the phone company is the largest in Scandinavia I guess they reaction to remedy the internet for a local town in the southern Sweden isn't on their top of the list. So today the internet is still not green and the latest estimate is 3pm this afternoon. Well guess what they said that yesterday as well. They just add 6 hours to the clock each time. 

Well one service they offered that I thought would be cool was that you could type in your mobile phone number and will receive a text message when the internet is green again. But yet again they would not accept my mobile number as it was from another vendor. Aint it sweet when companies just go to big and don't bother with the little people.

And on top of that I missed the latest episode of Heros last night, couldn't see digital TV either as its also requires the internet led to be green.

So appreciate when you internet led is green. You newer know when a storm is coming and having a ISP provider that is slower than a turtle to remedy infrastructure that people start to take for granted. 

Maybe wireless broadband is the future, haven't heard of any major phone company having 2 days downtime on the mobile phone net.

Just heard that in Denmark the record was topped for the most used active hour last day. More than 2.600.000 minutes was registered on the mobile net during a hour last day. That is 50% of the population was talking for 1 minute in that hour!

Yeah since you can read this blog entry I guess the internet led is green again.

The downtime was 3 days, on the 4th day the internet led did go green again :)

Apache Camel 1.6.1 Released

We the Camel riders is happy to announce that Apache Camel 1.6.1 has been released.

This is a maintenance release with approx 93 issues resolved. As we want the 1.6.x series to be production stable the next 1.6.2 release should only contain important bug fixes. Its important for the Camel community that uses of 1.6.x in production can rely on that we wont break or anyhow compromise the release.

All future development and features go into the 2.0 release.

Apache Camel online training

I take my good employee hat on and posts about this new offerings we have.

My employer Progress FUSE now offers virtual training for Apache Camel.

On-line training for Apache ServiceMix with Camel

Interactive classes without having to travel

Not getting the most out of your open source integration projects? Register today for one of our travel-free Apache ServiceMix with Camel classes. This is an intensive two-day, instructor-led, live training class that is delivered in a virtual classroom via the Web.

The course includes lectures and hands-on, code-level exercises targeted for developers and architects. Throughout the course the instructor, a teaching assistant and a member of the Progress FUSE Technical Services team are available to answer questions and assist with any technical issues. Click here to view the full agenda.

Real life story - Camel help track vehicles in Australia

I do think it was time for a break in my blog series on the progress on Apache Camel 2.0, and post a little intermission with a real life story.

A long time Camel user and contributor (Thanks Christopher for contributing to the Camel community with your great blogs, patches and involvement in the forums), Christopher Hunt, posted a great blog entry on his latest project - Titan Class goes into production. He uses a variety of various OSS projects to facilitate an application that is capable of tracking vehicles etc. 

I encourage you to take a minute to read his blog entry and enjoy the great screenshot of the application in action. I know its not often we can present nice and sexy screenshots with Camel.

Christopher have listed the Open Source projects used and its nice to see how diverse the list is and that its possible to build such applications. Imagine what it would have taken to do that 5-10 years ago in a single R&D department in a large corporation? Thanks to the innovation and spirit in the OSS space its now possible. And yes we gotta thank Google for doing Google Earth as well :)

On the road to Camel 2.0 - Asynchronous routing

We have rewritten the Asynchronous routing in Camel 2.0.

The new Async API in Camel 2.0 leverages in much greater detail the Java Concurrency API and its support for executing tasks asynchronous. Therefore the Camel Async API should be familiar for users with knowledge of the Java Concurrency API.

Before we dig into this matter there are a few concepts we need to discuss as a background material we must understand before using the Async API. The concept is general for asynchronous messaging and will apply for other Integration Frameworks as such.

As a client we can submit a message as either:

- request only

- request reply

The former is the postal service example where we send a postal mail and but a letter in a letterbox. We do not expect a reply in this conversation.

The latter is on the web where we using a web browser request to visit a web page and the remote web server replies with the web content.

The invocation and processing for both of them can happen either:

- synchronous

- asynchronous

From the client point of view, that is.

By using synchronous the client will wait until the conversation is over before continuing. With asynchronous the control to the client is returned immediately after the message have been submitted. The client can in the mean time do other work while the message is being routed and processed. At any given time in the future the client can decide to check whether the task is finished or not. In fact the client can wait until the task is complete and its result is returned to the client.

All together we have 2 x 2 combinations to understand. In this blog I will only show 1 of them. The Camel documentation contains all 4 of them with more details.

Asynchronous Request Reply

The asynchronous request reply is where the client sends a message to an Endpoint and the control is returned immediately back to the client. The message however is processed in another thread, the asynchronous thread. The client can continue doing other work and at the same time the asynchronous thread is processing the message. This is illustrated in the diagram below:

  

1. The client sends an Async Request Reply message over Http to Camel. The control is immediately returned to the client application, that can continue and do other work while Camel routes the message.
2. Camel invokes an external TCP service using synchronous Request Reply. The client application can do other work simultaneously.
   
3. The client wants to get the reply so it uses the Future handle it got as response from step 1. With this handle it retrieves the reply, wait if nessasary if the reply is not ready.
   

Asynchronous Request Reply Example

Suppose we want to call a Http service but it is usually slow and thus we do not want to block and wait for the response, as we can do other important computation. So we can initiate an Async exchange to the Http endpoint and then do other stuff while the slow Http service is processing our request. And then a bit later we can use the Future handle to get the response from the Http service. 

First we define some routes in Camel. One for the Http service where we simulate a slow server as it takes at least 1 second to reply. And then other route that we want to invoke while the Http service is on route. This allows you to be able to process the two routes simultaneously:

// The mocks are here for unit test

// Some other service to return a name

// this is invoked synhronously

from("direct:name")

    .transform(constant("Claus")).to("mock:result");

// Simulate a slow http service (delaying 1 sec)

// we want to invoke async

from("jetty:http://0.0.0.0:9080/myservice")

    .delay(1000)

    .transform(constant("Bye World"))

    .to("mock:result");

And then we have the client API where we call the two routes and we can get the responses from both of them. As the code is based on unit test there is a bit of mock in there as well:

MockEndpoint mock = getMockEndpoint("mock:result");

// We expect the name job to be faster than the async

// job even though the async job was started first

mock.expectedBodiesReceived("Claus", "Bye World");

// Send a async request/reply message to the http endpoint

Future future = template.asyncRequestBody("http://0.0.0.0:9080/myservice",

                          "Hello World");

// We got the future so in the meantime we can do other stuff

// as this is Camel so lets invoke another request/reply

// route but this time is synchronous

String name = template.requestBody("direct:name",

                  "Give me a name", String.class);

assertEquals("Claus", name);

// Okay we got a name and we have done some other

// work at the same time the async route is running,

// but now its about time to wait and get get the response

// from the async task

// We use the extract future body to get the response

// from the future (waiting if needed) and then return

// a string body response. This allows us to do this in a

// single code line instead of using the JDK Future API

// to get hold of it, but you can also use that if you want

String response = template.extractFutureBody(future, String.class);

assertEquals("Bye World", response);

assertMockEndpointsSatisfied();

Summary

Its now much easier to do asynchronous messaging with Apache Camel. The Client API has be rewritten so it resembles and uses the Java Concurrency API. The Camel documentation contains much more information and also about the new async DSL that can be used within the route itself to turn a route into asynchronous.

On the road to Camel 2.0 - Interceptors round two

A week have passed since the last blog post on interceptors in Apache Camel.

So this is round two, where I present the latest updates and the new whistles and bells features added recently.

With this overhaul of the interceptors in Camel 2.0 we fell that they are first class citizen in the Camel family and that they will provide value in the integration space.

To recap Camel supports 3 kinds of interceptors:

1. intercept
   
2. interceptFrom
   
3. interceptSendToEndpoint
   

Ad 1)

Intercept is the regular interceptor that is like a AOP before. Its triggered before a message is forwarded to the next step in the route path. Camel also leverages this internally to apply needed processing of messages during routing such as JMX instrumentation, Tracing, Error Handling and more.

What we have done lately is to improve the intercept with syntax sugar so you can define intercept as regular routing rules that you are already familiar with. 

So for instance to do the Hello World logging AOP we just do:

intercept().to("log:hello");

And Camel will thus log the message at each processing step while being routed.

As intercept() is also a regular route you can do routing as well, so you can do a little detour if you like:

intercept().to("log:hello")

    .to("bean:sanityCheck").delay(100);

Camel have build in support for predicates, so we have added this to the intercept as well. This allows you to attach a predicate to the intercept to let it only trigger in certain conditions. For instance to only trigger if the message is a test message we can add the when predicate as:

intercept().when(header("test").isEqualTo("true"))

    .to("log:hello");

So what is next? Well what if you want to stop continue routing, lets say the test message should not be routed normally but intercepted and logged. Well we have added support for stop as a general purpose stop continue routing. So we just prepend stop() to our intercept route:

intercept().when(header("test").isEqualTo("true"))

    .to("log:hello").stop();

Ad 2)

InterceptFrom is opposed to intercept only triggered once = when a new message arrives to our route. So this allows you to intercept any incoming messages and e.g. log them.

interceptFrom().to("log:incoming");

Well recently we added a new whistle and bells feature to this interceptor. You can now filter by endpoint URI. So if you only want to intercept certain endpoints you can filter using:

• exact match
  
• match by wildcard
  
• match by regular expression
  

Exact match is to match a single endpoint, and its just to provide the endpoint URI:

interceptFrom("activemq:queue:order").to("log:neworder");

Wildcards is supported by using a * in the end of the uri. So to match all jms queues you can do:

interceptFrom("activemq:queue:*").to("log:neworder");

And you can use regular expression for fine grained matching, to match for instance a gold and silver queues:

interceptFrom("activemq:queue:(gold|silver)")

    .to("log:neworder");

Camel provides the real intercepted endpoint URI as a message header with the key: Exchange.INTERCEPTED_ENDPOINT.

So in the sample above it will contain either: "activemq:queue:gold" or "activemq:queue:silver". This allows you to known which endpoint was intercepted.

Ad 3)

InterceptSendToEndpoint is triggered when you are about to send a message to the given endpoint. It basically intercepts the Producer. So this allows you for instance to log all outgoing messages as:

interceptSendToEndpoint().to("log:outgoing");

And just like interceptFrom it also have the same URI matching, so you can for instance intercept all cxf based endpoints such as:

interceptSendToEndpoint("cxf:*).to("log:callingwebservice");

Oh and just as intercept they all support the when predicate. So you can attach a predicate to only trigger in certain conditions. Can for instance be used to patch a message before sending:

interceptSendToEndpoint("cxf:*)

    .when().xpath("//order@id = '0')

    .to("bean:fixMissingOrderId");

The interceptSendToEndpoint brings in a new interesting feature as you can use it to mock endpoints in unit test. Lets say you write a unit test to invoke a http service to retrieve some data. With the interceptSendToEndpoint() we can intercept this and construct our own canned response. But how do you avoid invoking the real http endpoint? Well we added the option skipSendToOriginalEndpoint() to force Camel to not send it to the real intended endpoint. That leaves us with:

interceptSendToEndpoint("http:*")

    .skipSendToOriginalEndpoint().to("bean:simulateResponse");

Well I guess the 3 minutes is up and its time to end round two. Next blog entry will be on another subject as I kinda got full with interceptors now :)

The Camel wiki page for intercept has been updated with the latest details.

On the road to Camel 2.0 - Interceptors

Camel 2.0 have the intercept mechanism but it comes in different flavors.

They have the same common goal to intercept an message while its being routed and allows to do some custom work or processing. 

Before digging into showing code we distill the two distinct flavors as:

1) the classic AOP interceptor that is applied at each step in the route path

2a) route interceptors that intercept incoming messages

  and its related

2b) endpoint interceptors that intercept message about to be sent to an endpoint

Ad 1)

The classic AOP interceptors is defined in the interface org.apache.camel.spi.InterceptStrategy that allows you to attach a custom org.apache.camel.Processor with the work you want to do. This interceptor is mostly used internally in Camel to apply needed work that each message must undergo before they are continued routed to the next node in the route path.

We are looking into adding some syntax sugar so you can attach your own code logic without using the Camel API, for instance to use POJO. Expect this are to improve in the future.

Ad 2a)

As the Camel wiki documentation for interceptor was a bit sparse in this area I did some work yesterday to improve it and add some samples.

This interceptor is used for intercepting any new messages coming into Camel (i.e. think it as all the from DSL being intercepted).

For instance to log all incoming messages you can do:

intercept().to("log:received");

from("jms:queue:neworder").to("bean:ordeService?method=newOrder").to("jms:queue:handleorder");

People that already is familiar with Camel could know that Camel have extensive Predicate support. And with intercept that is no exceptions. So what we can do is to attach a predicate to the intercept to only trigger for certain conditions.

For instance to do a bit of custom processing on test messages received, we can add an interceptor with a predicate to determine if whether its a test message. If so we route it to our custom processor where we can "fixup" the test message before we let the message continue being routed from the origin of interception

intercept()

    .when(header("usertype").isEqualTo("test"))

    .process(new MyTestServiceProcessor());

Well what if you wanted to filter our test message instead? Well Camel supports a stop DSL keyword allowing Camel to stop continue routing. So in the sample above we could just append stop() in the end of the route. 

intercept()

    .when(header("usertype").isEqualTo("test"))

    .stop();

As the intercept() is also just a route you have all the DSLs at your fingertips.

Ad 2b)

This is a new interceptor introduced in Camel 2.0m2. The idea is to allow interception before a message is sent to a given Endpoint. So for instance if we want to do some custom processing before we send a message to the neworder JMS queue we can do:

interceptSendToEndpoint("jms:queue:neworder")

    .process(new MyJmsNewOrderProcessor());

So when anyone using the Camel API to send a JMS message to that given endpoint jms:queue:neworder, the producer is intercepted and the message is routed to our MyJmsNewOrderProcessor where we can alter the message or whatever we want to do. And afterwards the message is send to the original intended endpoint. The default behavior is to afterwards send it to the intended endpoint. But if you want to skip this you can add the stop() DSL to the route. We use the stop() keyword as this interceptor shares the same code base with the other interceptor, and thus also DSL keywords. We might consider separating the code to introduce a skip() DSL keyword as its better expression what it does, skipping sending the message to the intended endpoint.

So we could use this to intercept sending to the handleorder JMS queue and e.g. store it in a file instead.

// notice: use stop() to skip sending to the intended endpoint.

interceptSendToEndpoint("jms:queue:handleorder")

    .to("file://output/orders").stop();

We have a few other wacky ideas that we are considering. For instance why not allow wildcards or reg exp expressions in the intercepted endpoint uri so you can intercept any JMS queue or a group of queues.

Well that's it for now. Just wanted to give a bit of update on the interceptor side in Camel.

On the road to Camel 2.0 - Try Catch Finally

Today I have just completed an overhaul of the try catch finally DSLs we have in Apache Camel.

And since I improved (hmm added) the documentation to the Apache Camel wiki I might as well do a blog about it as well :)

Using try catch finally in Apache Camel

Camel supports the Java equivalent of try .. catch and finally directly in the DSL.

It aims to work like its Java sisters but with more power. Especially in Camel 2.0 where we gave this feature an overhaul.

In Camel we prefix the keywords with do to avoid having same keyword as Java. So we have:

• doTry
  
• doCatch
  
• doFinally
  
• end to end the block in Java DSL (Spring DSL have the </doTry> tag to end)

About doCatch and its power over Java

The doCatch in Camel is empowered over its Java sister. First of all you can define multiple exceptions to catch in a single block. And secondly you can attach a onWhen predicate to signal if the catch should trigger or not at runtime.

To simulate rehrowing an exception from a doCatch you should use the handled predicate. If its evaluated to false Camel will reattach the exception on the Exchange.

And just like Java the order in which you have multiple doCatch blocks matter. Camel will iterate from the top going down and use the first doCatch that matches the exception and if the onWhen predicate matches as well (if any provided). This is the same behavior as the Exception Clause.

Using try .. catch .. finally in Java DSL

In the route below we have all keywords in action. As the code is based on a unit test we route using Mock.

from("direct:start")

    .doTry()

        .process(new ProcessorFail())

        .to("mock:result")

    .doCatch(IOException.class, IllegalStateException.class)

        .to("mock:catch")

    .doFinally()

        .to("mock:finally")

    .end();

And here we have the same route in Spring DSL:

<route>

    <from uri="direct:start"/>

    <!-- here the try starts. its a try .. catch .. finally just as regular java code -->

    <doTry>

        <process ref="processorFail"/>

        <to uri="mock:result"/>

        <doCatch>

            <!-- catch multiple exceptions -->

            <exception>java.io.IOException</exception>

            <exception>java.lang.IllegalStateException</exception>

            <to uri="mock:catch"/>

        </doCatch>

        <doFinally>

            <to uri="mock:finally"/>

        </doFinally>

    </doTry>

</route>

There are more samples in the Camel Try Catch Finally documentation that also demonstrates the onWhen and handled predicates and what they are used for.

The overhaul was needed as it really brings the power of using try .. catch .. finally up to the same level as the exception clauses and error handlers in Camel. But having them right at your fingertips as regular Java like try .. catch .. finally brings the gaps from thinking Java to EIP patterns a bit closer.

PS: Mind that the static wiki documentation takes a few hours to be updated based on the dynamic changes I recently added, so some of the links might not work until then.