anchor.diff:  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], 
  +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.
   
  
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:  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 xref:components::mina-component.adoc[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 necessary if the reply is not ready.
  