Disruptor Component
Available as of Camel 2.12
The disruptor:
component provides asynchronous SEDA behavior much as the standard SEDA Component, but utilizes a Disruptor instead of a BlockingQueue utilized by the standard SEDA.
Alternatively, a disruptor-vm:
endpoint is supported by this component, providing an alternative to the standard VM.
As with the SEDA component, buffers of the disruptor:
endpoints are only visible within a single CamelContext and no support is provided for persistence or recovery. The disruptor-vm:
endpoints provides support for communication across CamelContexts instances (provided camel-disruptor.jar
is on the system/boot classpath).
The main advantage of choosing to use the Disruptor Component over the SEDA or the VM Component is performance in use cases where there is high contention between producer(s) and/or multi-casted or concurrent consumers. In those cases, significant increases of throughput and reduction of latency has been observed. Performance in scenarios without contention is comparable to the SEDA and VM Components.
The Disruptor is implemented with the intention of mimicking the behavior and options of the SEDA and VM Components as much as possible.
The main differences are:
- The buffer used is always bounded in size (default
1024
exchanges). - As a the buffer is always bounded, the default behavior for the Disruptor is to block while the buffer is full instead of throwing an exception. This default behavior may be configured on the component (see options).
- Disruptor endpoints don't implement the
BrowsableEndpoint
interface. As such, the exchanges currently in the Disruptor can't be retrieved, only the number of exchanges. - Disruptor requires its consumers (multicasted or otherwise) to be statically configured. Adding or removing consumers on the fly requires complete flushing of all pending exchanges in the Disruptor.
- As a result of the reconfiguration: data sent over a Disruptor is directly processed and 'gone' if there is at least one consumer. Late joiners receive new exchanges published after they joined.
- The
pollTimeout
option is not supported by the Disruptor Component. - When a producer blocks on a full Disruptor, it does not respond to thread interrupts.
Maven users will need to add the following dependency to their pom.xml
for this component:
<dependency> <groupId>org.apache.camel</groupId> <artifactId>camel-disruptor</artifactId> <version>x.x.x</version> <!-- use the same version as your Camel core version --> </dependency>
URI Format
disruptor:someName[?options]
or
disruptor-vm:someName[?options]
Where someName
can be any string that uniquely identifies the endpoint within the current CamelContext (or across contexts in case of disruptor-vm:
).
You can append query options to the URI in the following format:
?option=value&option=value&...
Options
All the following options are valid for both the disruptor:
and disruptor-vm:
components:
Name | Default | Description |
---|---|---|
|
| The maximum capacity of the Disruptor's ring buffer. Will be effectively increased to the nearest power of two. Note: Care should be taken when using this option. The size is determined by the value specified when the first endpoint is created. Each endpoint must therefore specify the same size. |
|
| Component only: The maximum default size (capacity of the number of messages it can hold) of the Disruptors ring buffer. This option is used if size is not in use. |
|
| Component only: Additional option to specify the |
|
| Number of concurrent threads processing exchanges. |
|
| Option to specify whether the caller should wait for the asynchronous task to complete before continuing. The following options are supported:
The first two values are self-explanatory. The last value, See Async messaging for more details. |
|
| Timeout (in milliseconds) before a seda producer will stop waiting for an asynchronous task to complete. See Disable the |
|
| Component only: Allows to set the default allowance of multiple consumers for endpoints created by this component used when |
multipleConsumers | false | Specifies whether multiple consumers are allowed. If When |
|
| Whether to limit the number of By default, an exception will be thrown if a Disruptor endpoint is configured with a greater number. When |
|
| Whether a thread that sends messages to a full Disruptor will block until the ring buffer's capacity is no longer exhausted. By default, the calling thread will block and wait until the message can be accepted. When |
|
| Component only: configures the producer's default behavior when the ring buffer is full for endpoints created by this component. This option is ignored when |
|
| Defines the strategy used by consumer threads to wait on new exchanges to be published. The following options are supported:
Refer to the section below for more information on this subject |
|
| Component only: Allows to set the default wait strategy for endpoints created by this component used when |
|
| Defines the producers allowed on the Disruptor. The following options are supported:
|
|
| Component only: Allows to set the default producer type for endpoints created by this component used when |
Wait strategies
The wait strategy effects the type of waiting performed by the consumer threads that are currently waiting for the next exchange to be published. The following strategies can be chosen:
Name | Description | Advice |
---|---|---|
| Blocking strategy that uses a lock and condition variable for Consumers waiting on a barrier. | This strategy can be used when throughput and low-latency are not as important as CPU resource. |
| Sleeping strategy that initially spins, then uses a | This strategy is a good compromise between performance and CPU resource. Latency spikes can occur after quiet periods. |
| Busy Spin strategy that uses a busy spin loop for Consumers waiting on a barrier. | This strategy will use CPU resource to avoid syscalls which can introduce latency jitter. It is best used when threads can be bound to specific CPU cores. |
| Yielding strategy that uses a | This strategy is a good compromise between performance and CPU resource without incurring significant latency spikes. |
Use of Request Reply
The Disruptor 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("disruptor:input"); from("disruptor: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 disruptor:input
buffer. As it is a Request Reply message, we wait for the response. When the consumer on the disruptor:input
buffer is complete, it copies the response to the original message response.
Concurrent consumers
By default, the Disruptor endpoint uses a single consumer thread, but you can configure it to use concurrent consumer threads. So instead of thread pools you can use:
from("disruptor:stageName?concurrentConsumers=5") .process(...)
As for the difference between the two, note a thread pool can increase/shrink dynamically at runtime depending on load, whereas the number of concurrent consumers is always fixed and supported by the Disruptor internally so performance will be higher.
Threadpools
Be aware that adding a thread pool to a Disruptor endpoint by doing something like:
from("disruptor:stageName") .thread(5) .process(...)
Can wind up with adding a normal BlockingQueue to be used in conjunction with the Disruptor, effectively negating part of the performance gains achieved by using the Disruptor. Instead, it's recommended to directly configure the number of threads that process messages on a Disruptor endpoint using the concurrentConsumers
option.
Sample
In the route below we use the Disruptor to send the request to this asynchronous 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 disruptor that is async .to("disruptor:next") // return a constant response .transform(constant("OK")); from("disruptor: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 Disruptor from another thread for further processing. Since this is from a unit test, it will be sent to a mock
endpoint where we can do assertions in the unit test.
Using multipleConsumers
In this example we have defined two consumers and registered them as spring beans.
<!-- define the consumers as spring beans --> <bean id="consumer1" class="org.apache.camel.spring.example.FooEventConsumer"/> <bean id="consumer2" class="org.apache.camel.spring.example.AnotherFooEventConsumer"/> <camelContext xmlns="http://camel.apache.org/schema/spring"> <!-- define a shared endpoint which the consumers can refer to instead of using url --> <endpoint id="foo" uri="disruptor:foo?multipleConsumers=true"/> </camelContext>
Since we have specified multipleConsumers=true
on the Disruptor foo
endpoint we can have those two or more consumers receive their own copy of the message as a kind of pub-sub style messaging. As the beans are part of an unit test they simply send the message to a mock
endpoint.
Note the use of @Consume
to consume from the Disruptor.
public class FooEventConsumer { @EndpointInject(uri = "mock:result") private ProducerTemplate destination; @Consume(ref = "foo") public void doSomething(String body) { destination.sendBody("foo" + body); } }
Extracting disruptor
Information
If needed, information such as buffer size, etc. can be obtained without using JMX in this fashion:
DisruptorEndpoint disruptor = context.getEndpoint("disruptor:xxxx"); int size = disruptor.getBufferSize();