Ordinary Queue vs SEDA Queue

SEDA queues are just like a regular queue (and as Peter said above, in Camel they have a thread pool associated with them as part of the component). SEDA is an architecture. The SEDA component in Camel uses in-memory queues in your process and are a separate component in order to distinguish them from the other queue component in Apache camel, namely the JMS component.

SEDA is an acronym that stands for Staged Event Driven Architecture it is designed as a mechanism to regulate the flow between different phases of message processing. The idea is to smooth out the frequency of message output from an overall process so that it matches the input, It allows an enpoint´s consumer threads to offload the work of long-running operations into the background, thereby freeing them up to consume messages from the transport. When an exchange is passed to a seda: endpoint, it is placed into a BlockingQueue. The list exists within the Camel context, wich means that only those routes that are within the same context can be joined by this type of endpoint. The queue is unbounded by default, although that can be changed by setting the size attribute on the URI of the consumer.

By default, a single thread assigned to the endpoint reads exchanges off the list and processes them through the route. As seen in the proceding example, it is possible to increase the number of concurrenctConsumers to ensure that exchanges are getting processed from that list in a timely fashion.

The SEDA pattern is best suited to processing the InOnly messages, where one route finishes processing and hands off to another to deal with the next phase. It is possible to ask for a response from seda:endpoint by calling it when the message exchange pattern is InOut.

Reference: Apache Camel Developer´s Cookbook