Normal queue versus SEDA queue

Question

Being new to Apache Camel, I recently looked at its long list of components and came across their support for the SEDA queue components .

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

After reading this article, I can’t say what a difference there is between the SEDA queue and the regular “regular” queue! Both cover the concept of decoupling systems using asynchronous queues.

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

But if it's just architecture, then why is the SEDA lineup using the special Apache Camel component?

Answer 1

SEDA queues are similar to another 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 Camel SEDA component uses in-memory queues in your process and is a separate component to distinguish them from another Apache camel queue component, namely the JMS component.

Answer 2

SEDA is an acronym for Event-Driven Architecture, it is designed as a mechanism for controlling the flow between the various stages of message processing. The idea is to smooth out the frequency of outputting messages from the overall process so that it matches the input. It allows consumer streams enpoint to unload the work of long-running operations in the bakground, thereby freeing them from consuming messages from transport. When an exchange is passed to seda: endpoint, it is placed in a BlockingQueue. The list exists in the context of a camel, which means that only those routes that are in the same context can be connected by this type of endpoint. The default queue is not limited, although you can change it by setting the size attribute in the user URI.

By default, one thread assigned to the endpoint reads exchanges from the list and processes them along the route. As you can see from the example procedure, you can increase the number of concurrenct participants to ensure timely processing of exchanges from this list.

The SEDA template is best suited for handling InOnly messages, where one route completes processing and passes hands to another to handle the next phase. you can request a response from seda: endpoint by calling it when the messaging template is InOut

Directory. Apache Camel Developer Cookbook

Answer 3

SEDA offers the decoupling of components on a single camel route. Or, for that matter, as part of one process., It helps you make asynchronous calls to other components ... its in memory lock. JMS, on the other hand, is used to decouple the entire system. JMS will have an external intermediary. SEDA willl simply creates a separate thread from the consumer component.