You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 11 Next »

SEDA Component

The 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.

Synchronous

The Direct component provides synchronous invocation of any consumers when a producer sends a message exchange.

URI format

seda:someName

Where someName can be any string to uniquely identify the endpoint within the current CamelContext

Options

Name

Default

Description

size

1000

The maximum size of the SEDA queue

Thread pools

Be 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(...)

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.

Error formatting macro: snippet: java.lang.NullPointerException

Here we send a Hello World message and expects the reply to be OK.

Error formatting macro: snippet: java.lang.NullPointerException

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.

  • No labels