Ordinary Queue vs SEDA Queue

Question

Being new to Apache Camel, I was recently reviewing its long list of components and stumbled upon their support for SEDA queue components.

The page didn't make much sense to me, so I did a couple of online searches for the term "SEDA queue" and got the wikipedia article here.

After reading that article, I can't tell what the difference is between a SEDA queue and a normal, "ordinary" queue! Both embrace the notion of decoupling systems through the use of asynchronous queues.

From the article, "SEDA" just sounds like an architecture that consists of placing a queue between each component. Is this correct?

But if it's just an architecture, then why is a "SEDA" queue a special Apache Camel component?

Immensurable

SEDA implies a thread attached to the queue like an ExecutorService (a queue and a thread pool) Perhaps that's what it means here. – Faust

I don't know if the documentation was updated since this question was asked, but it basically says that in the first line: "The seda: component provides asynchronous SEDA behavior, so that messages are exchanged on a BlockingQueue and consumers are invoked in a separate thread from the producer." – Poultry

Answer 1

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.

Ophthalmia

Answer 2

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

Shirr

Answer 3

SEDA offers decoupling of the components within a single camel route. Or for that matter within a single process. . Meaning it helps you make async calls to other components... its an in memory blockingqueue. On the other hand JMS is used for decoupling of the whole system.. JMS will have an external broker involved.. SEDA willl just create a separate thread from the consumer component

Batho