SEDAPage edited by Claus IbsenSEDA ComponentThe seda: component provides asynchronous SEDA behavior so that messages are exchanged on a BlockingQueue and consumers are invoked in a separate thread to the producer. Note that queues are only visible within a single CamelContext. If you want to communicate across CamelContext instances such as to communicate across web applications, see the VM component. This component does not implement any kind of persistence or recovery if the VM terminates while messages are yet to be processed. If you need persistence, reliability or distributed SEDA then try using either JMS or ActiveMQ.
URI format
seda:someName[?options]
Where someName can be any string to uniquely identify the endpoint within the current CamelContext.
Options
Changes in Camel 2.0In Camel 2.0 the SEDA component supports using Request Reply where the caller will wait for the Async route to complete. For instance:
from("mina:tcp://0.0.0.0:9876?textline=true&sync=true").to("seda:input");
from("seda:input").to("bean:processInput").to("bean:createResponse");
In the route above we have a TCP listener on port 9876 that accepts incoming requests. The request is routed to the seda:input queue. As its a Request Reply message we will wait for the response. So when the consumer on the seda:input queue is complete it will copy this response to the original message as response. Camel 1.x does not have this feature implemented, the SEDA queues in Camel 1.x will newer wait. Concurrent consumersBy default Camel uses a single consumer. You can configure the endpoint to use concurrent consumers. So instead of thread pools you can use:
from("seda:stageName?concurrentConsumers=5").process(...)
Difference between thread pools and concurrent consumersThe thread pool is a pool that dynamically can increase/shrink at runtime depending on load, the concurrent consumers is always fixed. Thread poolsBe aware that adding a thread pool to a seda endpoint by doing something like:
from("seda:stageName").thread(5).process(...)
can wind up with two BlockQueues. One from seda endpoint and one from the workqueue of the thread pool which may not be what you want. Instead, you might want to consider configuring a Direct endpoint with a thread pool which can process messages both synchronously and asynchronously. For example:
from("direct:stageName").thread(5).process(...)
You can also directly configure number of threads that process messages on seda endpoint using concurrentConsumers parameter. SampleIn the route below we use the SEDA queue to send the request to this async queue to be able to send a fire-and-forget message for further processing in another thread, and return a constant reply in this thread to the original caller.
public void configure() throws Exception {
from("direct:start")
// send it to the seda queue that is async
.to("seda:next")
// return a constant response
.transform(constant("OK"));
from("seda:next").to("mock:result");
}
Here we send a Hello World message and expects the reply to be OK.
Object out = template.requestBody("direct:start", "Hello World");
assertEquals("OK", out);
The "Hello World" message will be consumed from the SEDA queue from another thread for further processing, since this is from an unit test it will be sent to a mock endpoint where we can do assertions in the unit test. See Also
Change Notification Preferences
View Online
|
View Change
|
Add Comment
|
- [CONF] Apache Camel > SEDA confluence
- [CONF] Apache Camel > SEDA confluence
- [CONF] Apache Camel > SEDA confluence
- [CONF] Apache Camel > SEDA confluence
- [CONF] Apache Camel > SEDA confluence
- [CONF] Apache Camel > SEDA confluence
- [CONF] Apache Camel > SEDA confluence
- [CONF] Apache Camel > SEDA confluence
- [CONF] Apache Camel > SEDA confluence
- [CONF] Apache Camel > SEDA confluence
- [CONF] Apache Camel > SEDA confluence