Routing Slip

Camel supports the Routing Slip from the EIP patterns.

How do we route a message consecutively through a series of processing steps when the sequence of steps is not known at design-time and may vary for each message?


Attach a Routing Slip to each message, specifying the sequence of processing steps. Wrap each component with a special message router that reads the Routing Slip and routes the message to the next component in the list.


The Routing Slip eip supports 4 options, which are listed below.

Name Description Default Type


Required Expression to define the routing slip, which defines which endpoints to route the message in a pipeline style. Notice the expression is evaluated once, if you want a more dynamic style, then the dynamic router eip is a better choice.



Sets the uri delimiter to use.




Ignore the invalidate endpoint exception when try to create a producer with that endpoint.




Sets the maximum size used by the org.apache.camel.spi.ProducerCache which is used to cache and reuse producers when using this routing slip, when uris are reused. Beware that when using dynamic endpoints then it affects how well the cache can be utilized. If each dynamic endpoint is unique then its best to turn of caching by setting this to -1, which allows Camel to not cache both the producers and endpoints; they are regarded as prototype scoped and will be stopped and discarded after use. This reduces memory usage as otherwise producers/endpoints are stored in memory in the caches. However if there are a high degree of dynamic endpoints that have been used before, then it can benefit to use the cache to reuse both producers and endpoints and therefore the cache size can be set accordingly or rely on the default size (1000). If there is a mix of unique and used before dynamic endpoints, then setting a reasonable cache size can help reduce memory usage to avoid storing too many non frequent used producers.



Whether to disable this EIP from the route during build time. Once an EIP has been disabled then it cannot be enabled later at runtime.




Sets the description of this node.


See the cacheSize option for more details on how much cache to use depending on how many or few unique endpoints are used.

Exchange properties

The following exchange properties are set on each Exchange that are sent by the routing slip:

Property Type Description



Uri of the Endpoint that the message was sent to.



Uri of the Endpoint that the message was sent to.

Using Routing Slip

The Routing Slip EIP allows to route a message through a series of endpoints (the slip).

There can be 1 or more endpoint uris in the slip.

A slip can be empty, meaning that the message will not be routed anywhere.

The following route will take any messages sent to the Apache ActiveMQ queue cheese and use the header with key "whereTo" that is used to compute the slip (endpoint uris).


The value of the header ("whereTo") should be a comma-delimited string of endpoint URIs you wish the message to be routed to. The message will be routed in a pipeline fashion, i.e., one after the other.

The Routing Slip sets a property, Exchange.SLIP_ENDPOINT, on the Exchange which contains the current endpoint as it advanced though the slip. This allows you to know how far we have processed in the slip.

The Routing Slip will compute the slip beforehand which means, the slip is only computed once. If you need to compute the slip on-the-fly then use the Dynamic Router EIP instead.

The same example in XML is simply just:

  <from uri="activemq:cheese"/>

How is the slip computed

The Routing Slip uses an Expression to compute the value for the slip. The result of the expression can be one of:

  • String

  • Collection

  • Iterator or Iterable

  • Array

If the value is a String then the uriDelimiter is used to split the string into multiple uris. The default delimiter is comma, but can be re-configured.

Ignore Invalid Endpoints

The Routing Slip supports ignoreInvalidEndpoints (like Recipient List EIP). You can use it to skip endpoints which are invalid.


And in XML DSL it is an attribute on <routingSlip>:

  <from uri="direct:start"/>
  <routingSlip ignoreInvalidEndpoints="true">

Then let us say the myHeader contains the following two endpoints direct:foo,xxx:bar. The first endpoint is valid and works. However, the second one is invalid and will just be ignored. Camel logs at DEBUG level about it, so you can see why the endpoint was invalid.