Apache Camel: how a route stops itself at runtime

If you want to stop the route you are currently using, you can’t do it using

because it will wait for the current “inflight” message to be processed until “the end”.

So you need to do this async:

We do this when using the circuit breaker pattern. In the error handling processor we check if the circuit breaker goes to the OPEN state. If so, the route stops itself. Via another route we check periodically if the circuit breaker is in the HALF-OPEN state and start the route again.

Apache Camel: how to stop a message from being further processed

At one point in our latest project using Apache Camel, I wanted to stop a message from being further processed depending on a condition. This is quite easy to do with the route builder, for example:

If you already know that a message needs to be stopped right away in a Processor or a AggregationStrategy, there is an easy way to signal this without a seperate “stop-branch” in the route. You simply set the header ROUTE_STOP to TRUE like this:

And the message will not be further processed.

Also on:

Ralf Westphal: About simplicity in coding

In Who do you want to KISS? – About simplicity in coding Ralf Westphal reflects on what simplicity means in programming.

He observes that simplicity is relative, esp. relative to the “scarcest resource”. For Ralf “in the long run the scarcest resource therefore is reading or modification time“. In TDD there is a step when you can create simplicity in respect to reading/modification time:

It means, you need to find time to optimize for reading/modification later. Interestingly TDD has this time built in. That’s what the refactoring phase is for. During refactoring you apply the KISS principle once more – now creating simplicity for reading/modification time. If thereby the simplicity for coding time is destroyed so be it.

And even then, simplicity regarding code reading and modification is in the eye of the beholder. Some programmers like high level abstractions like higher order functions while other like a more verbose but easier to follow procedural style. This is often related to the level of experience:

A simple solution for one person can be a complicated solution for another person. Sad, but true. The only way out of this is to keep all team members close together in their competencies (as long as there is a chance one member needs to deal with another’s simple solutions).

(This is a repost from my other blog)

Also on:

Moving in

My name is Erik. I am a software developer. Most often, I program business “web” software in Java. My main focus is “software integration” that is using other software services in my services. So I’ll focus on this theme in this blog.

I have got a blog called kopf.lastig for 10 years that covers some software development stuff but also other things. Now I decided to move the sw dev stuff to this new blog “Erik on software integration”. I will write here in English and on my old blog in German.

This is a result of me taking a “free email course on building a blog that boosts your career” by John Sonmez from SimpleProgrammer.com .

At first, I will repost some of my old blog posts but later I will add new content.