...
Maven users will need to add the following dependency to their their pom.xml
for to use this EIP:
Code Block | ||||
---|---|---|---|---|
| ||||
<dependency> <groupId>org.apache.camel</groupId> <artifactId>camel-hystrix</artifactId> <version>x.x.x</version><!-- use the same version as your Camel core version --> </dependency> |
...
Name | Default Value | Type | Description | |||||
---|---|---|---|---|---|---|---|---|
commandKey | node id | String | Used to identify the hystrix command instance being used by the EIP to correlate statistics, circuit-breaker, properties, etc. By default this will be derived from the node id. | |||||
threadPoolKey | null | String | Used to define which thread-pool this command should run in. By default this is using the same key as the command key. | |||||
cacheKey | null | Expression | Specifies the cache key to use from the given expression. | |||||
initializeRequestContext | false | Boolean | When true, Camel will initialize a HystrixRequestContext during producer startup and use it for request scoped caching and request scoped logging. | |||||
corePoolSize | 10 | Integer | This property sets the core thread-pool size. This is the maximum number of HystrixCommands that can execute concurrently. | |||||
keepAliveTime | 1 | Integer | This property sets the keep-alive time, in minutes. | |||||
maxQueueSize | -1 | Integer | This property sets the maximum queue size of the BlockingQueue implementation. | |||||
queueSizeRejectionThreshold | 5 | Integer | This property sets the queue size rejection threshold — an artificial maximum queue size at which rejections will occur even if maxQueueSize has not been reached. | |||||
threadPoolMetricsRollingStatisticalWindowInMilliseconds | 10000 | Integer | This property sets the duration of the statistical rolling window, in milliseconds. This is how long metrics are kept for the thread pool. | |||||
threadPoolMetricsRollingStatisticalWindowBuckets | 10Integer | This property sets the number of buckets the rolling statistical window is divided into. | ||||||
|
|
| This property determines whether a circuit breaker will be used to track health and to short-circuit requests if it trips. | |||||
|
|
| This property sets the error percentage at or above which the circuit should trip open and start short-circuiting requests to fallback logic. | |||||
|
|
| This property, if | |||||
|
|
| This property, if | |||||
|
|
| This property sets the minimum number of requests in a rolling window that will trip the circuit. | |||||
|
|
| This property sets the amount of time, after tripping the circuit, to reject requests before allowing attempts again to determine if the circuit should again be closed. | |||||
|
|
| Used to identify the hystrix command. This option cannot be configured but is locked down to be the node id to make the command unique. | |||||
|
|
| This property sets the core thread-pool size. This is the maximum number of | |||||
|
|
| This property sets the maximum number of requests allowed to | a a If this maximum concurrent limit is hit then subsequent requests will be rejected. | ||||
|
|
| This property indicates which isolation | strategy strategy
| ||||
|
|
| This property indicates whether | the the | ||||
|
|
| This property sets the | time timeout in milliseconds | after which the caller will observe a timeout and walk away from the command executionfor execution completion. | |||
|
|
| This property indicates whether the execution of | execution should have a timeoutshould be timed. | ||||
|
|
| This property determines whether a call to | |||||
|
|
| This property sets the maximum number of requests | a a | .fallbackEnabled | true | Boolean | This property determines whether a call to HystrixCommand.getFallback() will be attempted when failure or rejection occurs. |
|
|
| Used to identify the hystrix group being used by the EIP to correlate statistics, circuit-breaker, properties, etc. | |||||
|
|
| This property sets the keep-alive time, in minutes. | |||||
|
|
| This property sets the maximum queue size of the | |||||
|
|
| This property sets the time to wait, in milliseconds, between allowing health snapshots to be taken that calculate success and error percentages and affect circuit breaker status. | |||||
|
|
| This property sets the maximum number of execution times that are kept per bucket. If more executions occur during the time they will wrap around and start over-writing at the beginning of the bucket. | |||||
|
|
| This property indicates whether execution latencies latency should be tracked and . The latency is calculated as percentiles. If they are disabled, all a percentile. If | |||||
|
|
| This property sets the number of buckets the | |||||
|
|
| This property sets the duration of the rolling window in which execution times are kept to allow for percentile calculations, in milliseconds.metricsRollingPercentileWindowBuckets | |||||
| 6
|
| This property sets the number of buckets the | rollingPercentile rolling statistical window | will be is divided into. | |||
|
|
| The following properties are related to capturing metrics from from | |||||
| 10
|
| This property sets the queue size rejection threshold — an artificial maximum queue size at which rejections will occur even if | |||||
|
|
| This property indicates whether HystrixCommand.getCacheKey() should be used with HystrixRequestCache to provide de-duplication functionality via request-scoped caching. | requestLogEnabled | true | Boolean | This property indicates whether HystrixCommand execution and events should be logged to HystrixRequestLogwhether | |
|
|
| Used to define which thread-pool this command should run in. By default this is using the same key as the group key. | |||||
|
|
| This property sets the number of buckets the rolling statistical window is divided into. | |||||
|
|
| This property sets the duration of the statistical rolling window, in milliseconds. This is how long metrics are kept for the thread pool. |
Example
Below is an example route that with showing an Hystrix endpoint that protects agains against slow operation and fallbacks by falling back to the inlined in-lined fallback route. By default the timeout request is just 1000 millis (1 sec) just 1000ms
so the http HTTP endpoint has to be fairly quick to succeed.
Code Block | ||
---|---|---|
| ||
from("direct:start") .hystrix() .to("http://fooservice.com/slow") .fallbackonFallback() .transform().constant("Fallback message") .end() .to("mock:result"); |
...
Code Block | ||||
---|---|---|---|---|
| ||||
<camelContext xmlns="http://camel.apache.org/schema/spring"> <route> <from uri="direct:start"/> <hystrix> <to uri="http://fooservice.com/slow"/> <fallback><onFallback> <transform> <constant>Fallback message</constant> </transform> </fallback>onFallback> </hystrix> <to uri="mock:result"/> </route> </camelContext> |
onFallback vs onFallbackViaNetwork
If you are using onFallback
then that is intended to be local processing only where you can do a message transformation or call a bean or something as the fallback. If you need to call an external service over the network then you should use onFallbackViaNetwork
that runs in another independent HystrixCommand
that uses its own thread pool to not exhaust the first command.
Configuring Hystrix Example
Hystrix has many options as listed in the table above. For example to set a higher timeout to to 5
seconds, and also let the circuit breaker wait wait 10
seconds before attempting a request again when the state was tripped to be open.
Code Block | ||
---|---|---|
| ||
from("direct:start") .hystrix() .configurehystrixConfiguration() .executionTimeoutInMilliseconds(5000).circuitBreakerSleepWindowInMilliseconds(10000) .end() .to("http://fooservice.com/slow") .fallbackonFallback() .transform().constant("Fallback message") .end() .to("mock:result"); |
...
Code Block | ||||
---|---|---|---|---|
| ||||
<camelContext xmlns="http://camel.apache.org/schema/spring"> <route> <from uri="direct:start"/> <hystrix> <hystrixConfiguration executionTimeoutInMilliseconds="5000" circuitBreakerSleepWindowInMilliseconds="10000"/> <to uri="http://fooservice.com/slow"/> <fallback><onFallback> <transform> <constant>Fallback message</constant> </transform> </fallback>onFallback> </hystrix> <to uri="mock:result"/> </route> </camelContext> |
...
Code Block | ||||
---|---|---|---|---|
| ||||
<camelContext xmlns="http://camel.apache.org/schema/spring"> <!-- a shared config which you can refer to from all your hystrix EIPs --> <hystrixConfiguration id="sharedConfig" executionTimeoutInMilliseconds="5000" circuitBreakerSleepWindowInMilliseconds="10000"/> <route> <from uri="direct:start"/> <hystrix hystrixConfigurationRef="sharedConfig"> <to uri="http://fooservice.com/slow"/> <fallback><onFallback> <transform> <constant>Fallback message</constant> </transform> </fallback>onFallback> </hystrix> <to uri="mock:result"/> </route> </camelContext> |
Example
You can find an example in the source code: camel-example-hystrix.