THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
The seda: component provides asynchronous SEDA behavior, so that messages are exchanged on a BlockingQueue and consumers are invoked in a separate thread to from 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(for example, communicating between 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.
...
Where someName can be any string to that uniquely identify identifies the endpoint within the current CamelContext.
You can append query options to the URI in the following format, ?option=value&option=value&...
| Info | ||
|---|---|---|
| ||
The excact same An exactly identical Seda endpoint URI must be used for both the producer endpoint and the consumer endpoint. Otherwise Camel will create a 2nd second Seda endpoint, even thought that the
Notice that we have to use the full URI including options in both the producer and consumer. |
Options
Name | Default | Description |
|---|---|---|
| | The maximum size of the SEDA queue. |
| | Camel 1.6.1/2.0: Number of concurrent threads processing exchanges. |
| | Camel 2.0: Option to specify if whether the caller should wait for the async task to be complete or not before continuing. The following 3 three options is are supported: |
| | Camel 2.0: Timeout in millis a seda producer will at most waiting for an async task to complete. See |
Changes in Camel 2.0
In Camel 2.0 the Seda component supports using Request Reply, where the caller will wait for the Async route to complete. For instance:
| Code Block |
|---|
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 it is a Request Reply message, we will wait for the response. So when When the consumer on the seda:input queue is complete, it will copy this copies the 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 consumers
By default Camel , the SEDA endpoint uses a single consumer . You thread, but you can configure the endpoint it to use concurrent consumersconsumer threads. So instead of thread pools you can use:
...
Difference between thread pools and concurrent consumers
The thread pool is a pool that dynamically can increase/shrink dynamically at runtime depending on load, whereas the concurrent consumers is are always fixed.
Thread pools
Be aware that adding a thread pool to a seda SEDA endpoint by doing something like:
| Code Block |
|---|
from("seda:stageName").thread(5).process(...)
|
can Can wind up with two BlockQueues. One from seda endpoint : one from the 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:
...
You can also directly configure number of threads that process messages on seda a SEDA endpoint using the concurrentConsumers parameter option.
Sample
In 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.
...
The "Hello World" message will be consumed from the SEDA queue from another thread for further processing, since . Since this is from an a unit test, it will be sent to a mock endpoint where we can do assertions in the unit test.
...