anchor.diff:  information on this page applies for Camel 2.0 and later.
   
   The Async API in Camel is primarily divided in two
  -areas +
  - 1. Initiating an Async messaging from the client +
  - 2. Turning a route into Async using the *threads*
  -DSL
  +areas:
  +
  + 1. Initiating an Async messaging from the client
  + 2. Turning a route into Async using the *threads* DSL
   
   Before we look at these two areas we start with a bit of background
   information and look at the concept from a higher level using
  
positive.code: 
   1. The client sends a Request only and we can
  still use xref:components::http-component.adoc[HTTP] despite http being
  Request Reply by nature. +
   2. Camel invokes an external xref:components::mina-component.adoc[TCP] service using
  synchronous Request Reply. The client
  application is still waiting. +
   3. The message is processed completely and the control is returned to
  the client.
  
  So why do you want to use synchronous xref:event-message.adoc[Request Only]? 
  Well if you want to know whether the message was processed
  successfully or not before continuing. With synchronous it allows you to
  wait while the message is being processed. In case the processing was
  
negative.code: The `threads` DSL leverages the JDK concurrency framework for multi-threading. It can be used to turn a synchronous route into
  Async. What happens is that from the point forwards
  from `threads` the messages are routed asynchronous in a new thread.
  Camel leverages the xref:asynchronous-routing-engine.adoc[asynchronous routing engine],
  which was re-introduced in Camel 2.4, to continue
  routing the Exchange asynchronously.
  
  