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

context.stopRoute()

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

So you need to do this async:

// ....
  private void shutdownRoute() {
    ShutdownRoute shutdownRoute = new ShutdownRoute(camelContext);
    new Thread(shutdownRoute).start();
    try {
      Thread.sleep(1000); // makes sure route is stop before this message finished 
    } catch (InterruptedException e) {
      // whatever
    }
  }
// ...

class ShutdownRoute implements Runnable {
  /** log instance */
  private Logger log = LoggerFactory.getLogger(ShutdownRoute.class.getName());
  
  private final CamelContext context;
  
  ShutdownRoute(final CamelContext cContext) {
    context = cContext;
    
  }
  
  @Override
  public void run() {
    try {      
      context.stopRoute(YOUR_ROUTE_ID);
    } catch (Exception e) {
      log.error("Failed to stop route",e);
    }
  }
}

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.

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:

from("direct:example")
  .choice()
    .when(header("someheader").isEqualTo("bla"))
      .stop()
  .end()

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:

if  (....) { // stop here 
      original.setProperty(Exchange.ROUTE_STOP, Boolean.TRUE);
      return original;
}

And the message will not be further processed.

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)

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.