[CONF] Apache Camel > Load Balancer

2014-04-13 Thread Bilgin Ibryam (Confluence)














  


Bilgin Ibryam edited the page:
 


Load Balancer   






...



 Code Block








language
xml


 




 
	



MyCustomException





 



 For further examples of this pattern look at this junit test case 
 



 Include Page









Using This Pattern


 










 View Online  · Like  · View Changes  
 Stop watching space  · Manage Notifications  


  

[CONF] Apache Camel > Load Balancer

2014-04-13 Thread Bilgin Ibryam (Confluence)














  


Bilgin Ibryam edited the page:
 


Load Balancer   






...



 Code Block









java


 




 from("direct:start").loadBalance()
	.circuitBreaker(2, 1000L, MyExceptionProcessorMyCustomException.class)
.to("mock:result");
 



...



 Code Block








language
xml


 




 
	



MyExceptionProcessor





 



...





   

[CONF] Apache Camel > Load Balancer

2014-04-13 Thread Bilgin Ibryam (Confluence)














  


Bilgin Ibryam edited the page:
 


Load Balancer   






...
The Circuit Breaker load balancer is a stateful pattern that monitors all calls for certain exceptions. Initially the Circuit Breaker is in closed state and passes all messages. If the are failures and the threshold is reached, it moves to open state and rejects all calls until halfOpenAfter timeout is reached. After this timeout is reached, if there is a new call, it will be passed pass and if the result is success the Circuit Breaker will move to closed state, or to open state if there was an error.
...



 Code Block








language
xml


 




 
  	


1000L1000"/>
MyExceptionProcessor 		 uri="mock:result"/>  MyExceptionProcessor

 uri="mock:result"/>
  
  

 



 The above example loads balance requests from direct:start to one of the available mock endpoint instances, in this case using a round robin policy. For further examples of this pattern look at this junit test case 
...






 View Online  · Like  · View Changes  
 Stop watching space  · Manage Notifications  


 


 


  This message was sent by Atlassian Confluence 5.0.3, Team Collaboration Software  






[CONF] Apache Camel > Load Balancer

2012-09-07 Thread confluence







Load Balancer
Page edited by Christian Mueller


Comment:
Removed the deprecated Camel 1.x documentations


 Changes (2)
 




...
| [Sticky|http://camel.apache.org/maven/current/camel-core/apidocs/org/apache/camel/processor/loadbalancer/StickyLoadBalancer.html] | Sticky load balancing using an _expression_ to calculate a correlation key to perform the sticky load balancing; rather like jsessionid in the web or JMSXGroupID in JMS. | | [Topic|http://camel.apache.org/maven/current/camel-core/apidocs/org/apache/camel/processor/loadbalancer/TopicLoadBalancer.html] | Topic which sends to all destinations (rather like JMS Topics) | 
| [Failover|http://camel.apache.org/maven/current/camel-core/apidocs/org/apache/camel/processor/loadbalancer/FailOverLoadBalancer.html] | *Camel 2.0:* In case of failures the exchange will be tried on the next endpoint. | 
| Weighted Round-Robin | *Camel 2.5:* The weighted load balancing policy allows you to specify a processing load distribution ratio for each server with respect to the others.  In addition to the weight, endpoint selection is then further refined using *round-robin* distribution based on weight. | | Weighted Random | *Camel 2.5:* The weighted load balancing policy allows you to specify a processing load distribution ratio for each server with respect to others.In addition to the weight, endpoint selection is then further refined using *random* distribution based on weight. | 
...
 h3. Failover 
*Available as of Camel 2.0* 
The {{failover}} load balancer is capable of trying the next processor in case an [Exchange] failed with an {{exception}} during processing. You can constrain the {{failover}} to activate only when one exception of a list you specify occurs. If you do not specify a list any exception will cause fail over to occur.  This balancer uses the same strategy for matching exceptions as the [Exception Clause] does for the *onException*. 
...


Full Content

Load Balancer

The Load Balancer Pattern allows you to delegate to one of a number of endpoints using a variety of different load balancing policies.

Built-in load balancing policies

Camel provides the following policies out-of-the-box:



 Policy 
 Description 


 Round Robin 
 The exchanges are selected from in a round robin fashion. This is a well known and classic policy, which spreads the load evenly. 


 Random 
 A random endpoint is selected for each exchange. 


 Sticky 
 Sticky load balancing using an _expression_ to calculate a correlation key to perform the sticky load balancing; rather like jsessionid in the web or JMSXGroupID in JMS. 


 Topic 
 Topic which sends to all destinations (rather like JMS Topics) 


 Failover 
 In case of failures the exchange will be tried on the next endpoint. 


 Weighted Round-Robin 
 Camel 2.5: The weighted load balancing policy allows you to specify a processing load distribution ratio for each server with respect to the others.  In addition to the weight, endpoint selection is then further refined using round-robin distribution based on weight. 


 Weighted Random 
 Camel 2.5: The weighted load balancing policy allows you to specify a processing load distribution ratio for each server with respect to others.In addition to the weight, endpoint selection is then further refined using random distribution based on weight. 


 Custom 
 Camel 2.8: From Camel 2.8 onwards the preferred way of using a custom Load Balancer is to use this policy, instead of using the @deprecated ref attribute. 





Load balancing HTTP endpointsIf you are proxying and load balancing HTTP, then see this page for more details.

Round Robin

The round robin load balancer is not meant to work with failover, for that you should use the dedicated failover load balancer. The round robin load balancer will only change to next endpoint per message.

The round robin load balancer is stateful as it keeps state of which endpoint to use next time.

Using the Fluent Builders

from("direct:start").loadBalance().
roundRobin().to("mock:x", "mock:y", "mock:z");



Using the Spring configuration


"camel" xmlns="http://camel.apache.org/schema/spring">
  
"direct:start"/>


"mock:x"/>
"mock:y"/>   
"mock:z"/> 

  




The above example loads balance requests from direct:start to one of the available mock endpoint instances, in this case using a round robin policy.
For further examples of this pattern look at this junit test case

Failover
The failover load balancer is capable of trying the next processor in case an Exchange failed with an exception during processing.
You can constrain the fail

[CONF] Apache Camel > Load Balancer

2012-08-29 Thread confluence







Load Balancer
Page edited by willem jiang


Comment:
Fix the broken link.


 Changes (1)
 




...
 The above example loads balance requests from *direct:start* to one of the available *mock endpoint* instances, in this case using a round robin policy. 
For further examples of this pattern look at [this junit test case|http://svn.apache.org/viewvc/camel/trunk/camel-core/src/test/java/org/apache/camel/processor/RoundRobinLoadBalanceTest.java?view=markup] 
 h3. Failover 
...


Full Content

Load Balancer

The Load Balancer Pattern allows you to delegate to one of a number of endpoints using a variety of different load balancing policies.

Built-in load balancing policies

Camel provides the following policies out-of-the-box:



 Policy 
 Description 


 Round Robin 
 The exchanges are selected from in a round robin fashion. This is a well known and classic policy, which spreads the load evenly. 


 Random 
 A random endpoint is selected for each exchange. 


 Sticky 
 Sticky load balancing using an _expression_ to calculate a correlation key to perform the sticky load balancing; rather like jsessionid in the web or JMSXGroupID in JMS. 


 Topic 
 Topic which sends to all destinations (rather like JMS Topics) 


 Failover 
 Camel 2.0: In case of failures the exchange will be tried on the next endpoint. 


 Weighted Round-Robin 
 Camel 2.5: The weighted load balancing policy allows you to specify a processing load distribution ratio for each server with respect to the others.  In addition to the weight, endpoint selection is then further refined using round-robin distribution based on weight. 


 Weighted Random 
 Camel 2.5: The weighted load balancing policy allows you to specify a processing load distribution ratio for each server with respect to others.In addition to the weight, endpoint selection is then further refined using random distribution based on weight. 


 Custom 
 Camel 2.8: From Camel 2.8 onwards the preferred way of using a custom Load Balancer is to use this policy, instead of using the @deprecated ref attribute. 





Load balancing HTTP endpointsIf you are proxying and load balancing HTTP, then see this page for more details.

Round Robin

The round robin load balancer is not meant to work with failover, for that you should use the dedicated failover load balancer. The round robin load balancer will only change to next endpoint per message.

The round robin load balancer is stateful as it keeps state of which endpoint to use next time.

Using the Fluent Builders

from("direct:start").loadBalance().
roundRobin().to("mock:x", "mock:y", "mock:z");



Using the Spring configuration


"camel" xmlns="http://camel.apache.org/schema/spring">
  
"direct:start"/>


"mock:x"/>
"mock:y"/>   
"mock:z"/> 

  




The above example loads balance requests from direct:start to one of the available mock endpoint instances, in this case using a round robin policy.
For further examples of this pattern look at this junit test case

Failover
Available as of Camel 2.0
The failover load balancer is capable of trying the next processor in case an Exchange failed with an exception during processing.
You can constrain the failover to activate only when one exception of a list you specify occurs. If you do not specify a list any exception will cause fail over to occur.  This balancer uses the same strategy for matching exceptions as the Exception Clause does for the onException.

Enable stream caching if using streamsIf you use streaming then you should enable Stream caching when using the failover load balancer. This is needed so the stream can be re-read after failing over to the next processor.

Failover offers the following options:



 Option 
 Type 
 Default 
 Description 


 inheritErrorHandler 
 boolean 
 true 
 Camel 2.3: Whether or not the Error Handler configured on the route should be used. Disable this if you want failover to transfer immediately to the next endpoint. On the other hand, if you have this option enabled, then Camel will first let the Error Handler try to process the message. The Error Handler may have been configured to redeliver and use delays between attempts. If you have enabled a number of redeliveries then Camel will try to redeliver to the same endpoint, and only fail over to the next endpoint, when the Error Handler is exhausted. 


 maximumFailoverAttempts 
 int 
 -1 
 Camel 2.3: A value to indicate after X failover attempts we should exhaust (give up). Use -1 to indicate never give up and continuously try to failover. Use 0 to never failover. And use e.g. 3 to failover at most 3 times before giving up. This option can be 

[CONF] Apache Camel > Load Balancer

2012-08-26 Thread confluence







Load Balancer
Page edited by Claus Ibsen


 Changes (1)
 




...
| Custom | *Camel 2.8:* From Camel 2.8 onwards the preferred way of using a custom [Load Balancer] is to use this policy, instead of using the @deprecated {{ref}} attribute. |  
{tip:title=Load balancing HTTP endpoints} If you are proxying and load balancing HTTP, then see [this page|How to use Camel as a HTTP proxy between a client and server] for more details. {tip}  
h3. Round Robin  
...


Full Content

Load Balancer

The Load Balancer Pattern allows you to delegate to one of a number of endpoints using a variety of different load balancing policies.

Built-in load balancing policies

Camel provides the following policies out-of-the-box:



 Policy 
 Description 


 Round Robin 
 The exchanges are selected from in a round robin fashion. This is a well known and classic policy, which spreads the load evenly. 


 Random 
 A random endpoint is selected for each exchange. 


 Sticky 
 Sticky load balancing using an _expression_ to calculate a correlation key to perform the sticky load balancing; rather like jsessionid in the web or JMSXGroupID in JMS. 


 Topic 
 Topic which sends to all destinations (rather like JMS Topics) 


 Failover 
 Camel 2.0: In case of failures the exchange will be tried on the next endpoint. 


 Weighted Round-Robin 
 Camel 2.5: The weighted load balancing policy allows you to specify a processing load distribution ratio for each server with respect to the others.  In addition to the weight, endpoint selection is then further refined using round-robin distribution based on weight. 


 Weighted Random 
 Camel 2.5: The weighted load balancing policy allows you to specify a processing load distribution ratio for each server with respect to others.In addition to the weight, endpoint selection is then further refined using random distribution based on weight. 


 Custom 
 Camel 2.8: From Camel 2.8 onwards the preferred way of using a custom Load Balancer is to use this policy, instead of using the @deprecated ref attribute. 





Load balancing HTTP endpointsIf you are proxying and load balancing HTTP, then see this page for more details.

Round Robin

The round robin load balancer is not meant to work with failover, for that you should use the dedicated failover load balancer. The round robin load balancer will only change to next endpoint per message.

The round robin load balancer is stateful as it keeps state of which endpoint to use next time.

Using the Fluent Builders

from("direct:start").loadBalance().
roundRobin().to("mock:x", "mock:y", "mock:z");



Using the Spring configuration


"camel" xmlns="http://camel.apache.org/schema/spring">
  
"direct:start"/>


"mock:x"/>
"mock:y"/>   
"mock:z"/> 

  




The above example loads balance requests from direct:start to one of the available mock endpoint instances, in this case using a round robin policy.
For further examples of this pattern look at this junit test case

Failover
Available as of Camel 2.0
The failover load balancer is capable of trying the next processor in case an Exchange failed with an exception during processing.
You can constrain the failover to activate only when one exception of a list you specify occurs. If you do not specify a list any exception will cause fail over to occur.  This balancer uses the same strategy for matching exceptions as the Exception Clause does for the onException.

Enable stream caching if using streamsIf you use streaming then you should enable Stream caching when using the failover load balancer. This is needed so the stream can be re-read after failing over to the next processor.

Failover offers the following options:



 Option 
 Type 
 Default 
 Description 


 inheritErrorHandler 
 boolean 
 true 
 Camel 2.3: Whether or not the Error Handler configured on the route should be used. Disable this if you want failover to transfer immediately to the next endpoint. On the other hand, if you have this option enabled, then Camel will first let the Error Handler try to process the message. The Error Handler may have been configured to redeliver and use delays between attempts. If you have enabled a number of redeliveries then Camel will try to redeliver to the same endpoint, and only fail over to the next endpoint, when the Error Handler is exhausted. 


 maximumFailoverAttempts 
 int 
 -1 
 Camel 2.3: A value to indicate after X failover attempts we should exhaust (give up). Use -1 to indicate never give up and continuously try to failover. Use 0 to never failover. And use e.g. 3 to failover at most 3 times before giving up. This option can be used whether or not roundRobin is enabled or 

[CONF] Apache Camel > Load Balancer

2012-01-27 Thread confluence







Load Balancer
Page edited by Glen Mazza


Comment:
editorial fixes


 Changes (19)
 




...
The Load Balancer Pattern allows you to delegate to one of a number of endpoints using a variety of different load balancing policies.  
h3. Build in Built-in load balancing policies 
 
Camel has out of the box the following policies: 
Camel provides the following policies out-of-the-box: 
|| Policy || Description || 
| [Round Robin|http://camel.apache.org/maven/current/camel-core/apidocs/org/apache/camel/processor/loadbalancer/RoundRobinLoadBalancer.html] | The exchanges is are selected from in a round robin fashion. This is a well known and classic policy. This policy, which spreads the load evenly. | 
| [Random|http://camel.apache.org/maven/current/camel-core/apidocs/org/apache/camel/processor/loadbalancer/RandomLoadBalancer.html] | A random endpoint is selected for each exchange. | 
| [Sticky|http://camel.apache.org/maven/current/camel-core/apidocs/org/apache/camel/processor/loadbalancer/StickyLoadBalancer.html] | Sticky load balancing using an _expression_ to calculate a correlation key to perform the sticky load balancing; rather like jsessionid in the web or JMSXGroupID in JMS. | | [Topic|http://camel.apache.org/maven/current/camel-core/apidocs/org/apache/camel/processor/loadbalancer/TopicLoadBalancer.html] | Topic which sends to all destinations (rather like JMS Topics) | 
| [Failover|http://camel.apache.org/maven/current/camel-core/apidocs/org/apache/camel/processor/loadbalancer/FailOverLoadBalancer.html] | *Camel 2.0:* In case of failures the exchange is will be tried on the next endpoint. | 
| Weighted Round-Robin | *Camel 2.5:* The weighted load balancing policy allows you to specify a processing load distribution ratio for each server with respect to the others.  In addition to the weight, endpoint selection is then further refined using *round-robin* distribution based on weight. | 
| Weighted Random | *Camel 2.5:* The weighted load balancing policy allows you to specify a processing load distribution ratio for each server with respect to others.In addition to the weight, endpoint selection is then further refined using *random* distribution based on weight. | | Custom | *Camel 2.8:* From Camel 2.8 onwards the preferred way of using a custom [Load Balancer] is to use this policy, instead of using the @deprecated {{ref}} attribute. | 
...
h3. Round Robin  
*Camel 1.x behavior* The round robin load balancer can actually be used to failover with Camel 1.x. This is no longer possible in Camel 2.x as the underlying [Error Handler] foundation has been significantly overhauled in Camel 2.x. Frankly the round robin load balancer in Camel 1.x was not thought to be used in a failover scenario.  *Camel 2.x behavior* 
The round robin load balancer is not meant to work with failover, for that you should use the dedicated *failover* load balancer. The round robin load balancer will only change to next endpoint per message.  
The round robin load balancer is statefull as it keeps state of which endpoint to use next time. 
 *Using the [Fluent Builders]* 
...
{code}  
So the The above example will load loads balance requests from *direct:start* to one of the available *mock endpoint* instances, in this case using a round robbin policy. 
For further examples of this pattern in use you could look at the [junit [this junit test case|http://svn.apache.org/viewvc/camel/trunk/camel-core/src/test/java/org/apache/camel/processor/LoadBalanceTest.java?view=markup] 
 h3. Failover *Available as of Camel 2.0* The {{failover}} load balancer is capable of trying the next processor in case an [Exchange] failed with an {{exception}} during processing. 
You can configure the {{failover}} with a list of specific exception to only failover. If you do not specify any exceptions it will failover over any exceptions. It uses the same strategy for matching exceptions as the [Exception Clause] does for the *onException*. 
You can constrain the {{failover}} to activate only when one exception of a list you specify occurs. If you do not specify a list any exception will cause fail over to occur.  This balancer uses the same strategy for matching exceptions as the [Exception Clause] does for the *onException*. 
 {info:title=Enable stream caching if using streams} 
If you use streaming then you should enable [Stream Caching] when using the failover load balancer. This is needed so the stream can be re-read when after failing over to the next processor. 
{in

[CONF] Apache Camel > Load Balancer

2011-06-21 Thread confluence







Load Balancer
Page edited by Claus Ibsen


 Changes (2)
 




...
| Weighted Round-Robin | *Camel 2.5:* The weighted load balancing policy allows you to specify a processing load distribution ratio for each server with respect to others.In addition to the weight, endpoint selection is then further refined using *round-robin* distribution based on weight. | | Weighted Random | *Camel 2.5:* The weighted load balancing policy allows you to specify a processing load distribution ratio for each server with respect to others.In addition to the weight, endpoint selection is then further refined using *random* distribution based on weight. | 
| Custom | *Camel 2.8:* From Camel 2.8 onwards the preferred way of using a custom [Load Balancer] is to use this policy, instead of using the @deprecated {{ref}} attribute. | 
 h3. Round Robin 
...
{code}  
 h3. Custom Load Balancer  You can use a custom load balancer (eg your own implementation) also.   An example using Java DSL: {snippet:id=e1|lang=java|url=""   And the same example using XML DSL: {snippet:id=e1|lang=xml|url=""   Notice in the XML DSL above we use  which is only available in *Camel 2.8* onwards. In older releases you would have to do as follows instead: {code:xml}   {code}  To implement a custom load balancer you can extend some support classes such as {{LoadBalancerSupport}} and {{SimpleLoadBalancerSupport}}. The former supports the asynchronous routing engine, and the latter does not. Here is an example: {snippet:id=e2|title=Custom load balancer implementation|lang=java|url=""
{include:Using This Pattern} 


Full Content

Load Balancer

The Load Balancer Pattern allows you to delegate to one of a number of endpoints using a variety of different load balancing policies.

Build in load balancing policies

Camel has out of the box the following policies:



 Policy 
 Description 


 Round Robin 
 The exchanges is selected in a round robin fashion. This is a well known and classic policy. This spreads the load even. 


 Random 
 A random endpoint is selected for each exchange 


 Sticky 
 Sticky load balancing using an _expression_ to calculate a correlation key to perform the sticky load balancing; rather like jsessionid in the web or JMSXGroupID in JMS. 


 Topic 
 Topic which sends to all destinations (rather like JMS Topics) 


 Failover 
 Camel 2.0: In case of failures the exchange is tried on the next endpoint. 


 Weighted Round-Robin 
 Camel 2.5: The weighted load balancing policy allows you to specify a processing load distribution ratio for each server with respect to others.In addition to the weight, endpoint selection is then further refined using round-robin distribution based on weight. 


 Weighted Random 
 Camel 2.5: The weighted load balancing policy allows you to specify a processing load distribution ratio for each server with respect to others.In addition to the weight, endpoint selection is then further refined using random distribution based on weight. 


 Custom 
 Camel 2.8: From Camel 2.8 onwards the preferred way of using a custom Load Balancer is to use this policy, instead of using the @deprecated ref attribute. 





Round Robin

Camel 1.x behavior
The round robin load balancer can actually be used to failover with Camel 1.x. This is no longer possible in Camel 2.x as the underlying Error Handler foundation has been significantly overhauled in Camel 2.x. Frankly the round robin load balancer in Camel 1.x was not thought to be used in a failover scenario.

Camel 2.x behavior
The round robin load balancer is not meant to work with failover, for that you should use the dedicated failover load balancer. The round robin load balancer will only change to next endpoint per message.

The round robin load balancer is statefull as it keeps state which endpoint to use next time.

Using the Fluent Builders

from("direct:start").loadBalance().
roundRobin().to("mock:x", "mock:y", "mock:z");



Using the Spring configuration


"camel" xmlns="http://camel.apache.org/schema/spring">
  
"direct:start"/>


"mock:x"/>
"mock:y"/>   
"mock:z"/> 

  




So the above example will load balance requests from direct:start to one of the available mock endpoint instances, in this case using a round robbin policy.
For further examples of this pattern in use you could look at the junit test case

Failover
Available as of Camel 2.0
The failover load balancer is capable of trying the next processor in case an Exchange failed with an exception during processing.
You can configure the failover with a list of specific exception to only failover. 

[CONF] Apache Camel > Load Balancer

2011-03-01 Thread confluence







Load Balancer
Page edited by Claus Ibsen


 Changes (1)
 




...
You can configure the {{failover}} with a list of specific exception to only failover. If you do not specify any exceptions it will failover over any exceptions. It uses the same strategy for matching exceptions as the [Exception Clause] does for the *onException*.  
{info:title=Enable stream caching if using streams} If you use streaming then you should enable [Stream Caching] when using the failover load balancer. This is needed so the stream can be re-read when failing over. {info}  
It has the following options: || Option || Type || Default || Description || 
...


Full Content

Load Balancer

The Load Balancer Pattern allows you to delegate to one of a number of endpoints using a variety of different load balancing policies.

Build in load balancing policies

Camel has out of the box the following policies:



 Policy 
 Description 


 Round Robin 
 The exchanges is selected in a round robin fashion. This is a well known and classic policy. This spreads the load even. 


 Random 
 A random endpoint is selected for each exchange 


 Sticky 
 Sticky load balancing using an _expression_ to calculate a correlation key to perform the sticky load balancing; rather like jsessionid in the web or JMSXGroupID in JMS. 


 Topic 
 Topic which sends to all destinations (rather like JMS Topics) 


 Failover 
 Camel 2.0: In case of failures the exchange is tried on the next endpoint. 


 Weighted Round-Robin 
 Camel 2.5: The weighted load balancing policy allows you to specify a processing load distribution ratio for each server with respect to others.In addition to the weight, endpoint selection is then further refined using round-robin distribution based on weight. 


 Weighted Random 
 Camel 2.5: The weighted load balancing policy allows you to specify a processing load distribution ratio for each server with respect to others.In addition to the weight, endpoint selection is then further refined using random distribution based on weight. 





Round Robin

Camel 1.x behavior
The round robin load balancer can actually be used to failover with Camel 1.x. This is no longer possible in Camel 2.x as the underlying Error Handler foundation has been significantly overhauled in Camel 2.x. Frankly the round robin load balancer in Camel 1.x was not thought to be used in a failover scenario.

Camel 2.x behavior
The round robin load balancer is not meant to work with failover, for that you should use the dedicated failover load balancer. The round robin load balancer will only change to next endpoint per message.

The round robin load balancer is statefull as it keeps state which endpoint to use next time.

Using the Fluent Builders

from("direct:start").loadBalance().
roundRobin().to("mock:x", "mock:y", "mock:z");



Using the Spring configuration


"camel" xmlns="http://camel.apache.org/schema/spring">
  
"direct:start"/>


"mock:x"/>
"mock:y"/>   
"mock:z"/> 

  




So the above example will load balance requests from direct:start to one of the available mock endpoint instances, in this case using a round robbin policy.
For further examples of this pattern in use you could look at the junit test case

Failover
Available as of Camel 2.0
The failover load balancer is capable of trying the next processor in case an Exchange failed with an exception during processing.
You can configure the failover with a list of specific exception to only failover. If you do not specify any exceptions it will failover over any exceptions. It uses the same strategy for matching exceptions as the Exception Clause does for the onException.

Enable stream caching if using streamsIf you use streaming then you should enable Stream caching when using the failover load balancer. This is needed so the stream can be re-read when failing over.

It has the following options:



 Option 
 Type 
 Default 
 Description 


 inheritErrorHandler 
 boolean 
 true 
 Camel 2.3: Whether or not the Error Handler configured on the route should be used or not. You can disable it if you want the failover to trigger immediately and failover to the next endpoint. On the other hand if you have this option enabled, then Camel will first let the Error Handler try to process the message. The Error Handler may have been configured to redelivery and use delays between attempts. If you have enabled a number of redeliveries then Camel will try to redeliver to the same endpoint, and only failover to the next endpoint, when the Error Handler is exhausted. 


 maximumFailoverAttempts 
 int 
 -1 
 Camel 2.3: A value to indicate after X failver attempts we should exhaust (give up). U

[CONF] Apache Camel > Load Balancer

2011-01-09 Thread confluence







Load Balancer
Page edited by Richard Kettelerij


Comment:
removed double header


 Changes (1)
 



...
{code}  
h4. Using this Pattern 
{include:Using This Pattern} 

Full Content

Load Balancer

The Load Balancer Pattern allows you to delegate to one of a number of endpoints using a variety of different load balancing policies.

Build in load balancing policies

Camel has out of the box the following policies:



 Policy 
 Description 


 Round Robin 
 The exchanges is selected in a round robin fashion. This is a well known and classic policy. This spreads the load even. 


 Random 
 A random endpoint is selected for each exchange 


 Sticky 
 Sticky load balancing using an _expression_ to calculate a correlation key to perform the sticky load balancing; rather like jsessionid in the web or JMSXGroupID in JMS. 


 Topic 
 Topic which sends to all destinations (rather like JMS Topics) 


 Failover 
 Camel 2.0: In case of failures the exchange is tried on the next endpoint. 


 Weighted Round-Robin 
 Camel 2.5: The weighted load balancing policy allows you to specify a processing load distribution ratio for each server with respect to others.In addition to the weight, endpoint selection is then further refined using round-robin distribution based on weight. 


 Weighted Random 
 Camel 2.5: The weighted load balancing policy allows you to specify a processing load distribution ratio for each server with respect to others.In addition to the weight, endpoint selection is then further refined using random distribution based on weight. 





Round Robin

Camel 1.x behavior
The round robin load balancer can actually be used to failover with Camel 1.x. This is no longer possible in Camel 2.x as the underlying Error Handler foundation has been significantly overhauled in Camel 2.x. Frankly the round robin load balancer in Camel 1.x was not thought to be used in a failover scenario.

Camel 2.x behavior
The round robin load balancer is not meant to work with failover, for that you should use the dedicated failover load balancer. The round robin load balancer will only change to next endpoint per message.

The round robin load balancer is statefull as it keeps state which endpoint to use next time.

Using the Fluent Builders

from("direct:start").loadBalance().
roundRobin().to("mock:x", "mock:y", "mock:z");



Using the Spring configuration


"camel" xmlns="http://camel.apache.org/schema/spring">
  
"direct:start"/>


"mock:x"/>
"mock:y"/>   
"mock:z"/> 

  




So the above example will load balance requests from direct:start to one of the available mock endpoint instances, in this case using a round robbin policy.
For further examples of this pattern in use you could look at the junit test case

Failover
Available as of Camel 2.0
The failover load balancer is capable of trying the next processor in case an Exchange failed with an exception during processing.
You can configure the failover with a list of specific exception to only failover. If you do not specify any exceptions it will failover over any exceptions. It uses the same strategy for matching exceptions as the Exception Clause does for the onException.

It has the following options:



 Option 
 Type 
 Default 
 Description 


 inheritErrorHandler 
 boolean 
 true 
 Camel 2.3: Whether or not the Error Handler configured on the route should be used or not. You can disable it if you want the failover to trigger immediately and failover to the next endpoint. On the other hand if you have this option enabled, then Camel will first let the Error Handler try to process the message. The Error Handler may have been configured to redelivery and use delays between attempts. If you have enabled a number of redeliveries then Camel will try to redeliver to the same endpoint, and only failover to the next endpoint, when the Error Handler is exhausted. 


 maximumFailoverAttempts 
 int 
 -1 
 Camel 2.3: A value to indicate after X failver attempts we should exhaust (give up). Use -1 to indicate newer give up and always try to failover. Use 0 to newer failover. And use e.g. 3 to failover at most 3 times before giving up. This option can be used whether or not round robin is enabled or not. 


 roundRobin 
 boolean 
 false 
 Camel 2.3: Whether or not the failover load balancer should operate in round robin mode or not. If not, then it will always start from the first endpoint when a new message is to be processed. In other words it restart from the top for every message. If round robin is enabled, then it keeps state and will continue with the next endpoint in a round robin fashion. When using round robin it will not stick to last known good endpo

[CONF] Apache Camel > Load Balancer

2010-10-27 Thread confluence







Load Balancer
Page edited by Ashwin Karpe


 Changes (7)
 



...
|| Option || Type || Default || Description || | roundRobin | boolean | false | The default value for round-robin is false. In the absence of this setting or parameter the load balancing algorithm used is random. 
| distributionRatio | String | none | The distributionRatio is a delimited String consisting on integer weights separated by delimiters for example "2:3:5". "2,3,5". The distributionRatio must match the number of endpoints and/or processors specified in the load balancer list. | 
| distributionRatioDelimiter | String | : , | The distributionRatioDelimiter is the delimiter used to specify the distributionRatio. If this attribute is not specified a default delimiter ":," is expected as the delimiter used for specifying the distributionRatio. | 
 h4. Using Weighted round-robin & random load balancing 
...
// round-robin from("direct:start") 
.loadBalance().weighted(true, "4:2:1") 
.loadBalance().weighted(true, "4:2:1" distributionRatioDelimiter=":") 
.to("mock:x", "mock:y", "mock:z");  //random from("direct:start") 
.loadBalance().weighted(false, "4,2,1", ",") 
.loadBalance().weighted(false, "4,2,1") 
.to("mock:x", "mock:y", "mock:z"); {code} 
...
  
distributionRatio="4,2,1" distributionRatioDelimiter="," distributionRatio="4-2-1" distributionRatioDelimiter="-" /> 
  
...

Full Content

Load Balancer

The Load Balancer Pattern allows you to delegate to one of a number of endpoints using a variety of different load balancing policies.

Build in load balancing policies

Camel has out of the box the following policies:



 Policy 
 Description 


 Round Robin 
 The exchanges is selected in a round robin fashion. This is a well known and classic policy. This spreads the load even. 


 Random 
 A random endpoint is selected for each exchange 


 Sticky 
 Sticky load balancing using an _expression_ to calculate a correlation key to perform the sticky load balancing; rather like jsessionid in the web or JMSXGroupID in JMS. 


 Topic 
 Topic which sends to all destinations (rather like JMS Topics) 


 Failover 
 Camel 2.0: In case of failures the exchange is tried on the next endpoint. 


 Weighted Round-Robin 
 Camel 2.5: The weighted load balancing policy allows you to specify a processing load distribution ratio for each server with respect to others.In addition to the weight, endpoint selection is then further refined using round-robin distribution based on weight. 


 Weighted Random 
 Camel 2.5: The weighted load balancing policy allows you to specify a processing load distribution ratio for each server with respect to others.In addition to the weight, endpoint selection is then further refined using random distribution based on weight. 





Round Robin

Camel 1.x behavior
The round robin load balancer can actually be used to failover with Camel 1.x. This is no longer possible in Camel 2.x as the underlying Error Handler foundation has been significantly overhauled in Camel 2.x. Frankly the round robin load balancer in Camel 1.x was not thought to be used in a failover scenario.

Camel 2.x behavior
The round robin load balancer is not meant to work with failover, for that you should use the dedicated failover load balancer. The round robin load balancer will only change to next endpoint per message.

The round robin load balancer is statefull as it keeps state which endpoint to use next time.

Using the Fluent Builders

from("direct:start").loadBalance().
roundRobin().to("mock:x", "mock:y", "mock:z");



Using the Spring configuration


"camel" xmlns="http://camel.apache.org/schema/spring">
  
"direct:start"/>


"mock:x"/>
"mock:y"/>   
"mock:z"/> 

  




So the above example will load balance requests from direct:start to one of the available mock endpoint instances, in this case using a round robbin policy.
For further examples of this pattern in use you could look at the junit test case

Failover
Available as of Camel 2.0
The failover load balancer is capable of trying the next processor in case an Exchange failed with an exception during processing.
You can configure the failover with a list of specific exception to only failover. If you do not specify any exceptions it will failover over any exceptions. It uses the same strategy for matching exceptions as the Exception Clause does for the onException.

It has the following options:



 Option 
 Type 
 Default 
 Description 


 inheritErrorHandler 
 boolean 
 tru

[CONF] Apache Camel > Load Balancer

2010-10-25 Thread confluence







Load Balancer
Page edited by Ashwin Karpe


 Changes (2)
 



...
{code}  
*As of Camel 2.6* 
*Available In Camel 2.6* 
 An example using Java DSL: 
...

Full Content

Load Balancer

The Load Balancer Pattern allows you to delegate to one of a number of endpoints using a variety of different load balancing policies.

Build in load balancing policies

Camel has out of the box the following policies:



 Policy 
 Description 


 Round Robin 
 The exchanges is selected in a round robin fashion. This is a well known and classic policy. This spreads the load even. 


 Random 
 A random endpoint is selected for each exchange 


 Sticky 
 Sticky load balancing using an _expression_ to calculate a correlation key to perform the sticky load balancing; rather like jsessionid in the web or JMSXGroupID in JMS. 


 Topic 
 Topic which sends to all destinations (rather like JMS Topics) 


 Failover 
 Camel 2.0: In case of failures the exchange is tried on the next endpoint. 


 Weighted Round-Robin 
 Camel 2.5: The weighted load balancing policy allows you to specify a processing load distribution ratio for each server with respect to others.In addition to the weight, endpoint selection is then further refined using round-robin distribution based on weight. 


 Weighted Random 
 Camel 2.5: The weighted load balancing policy allows you to specify a processing load distribution ratio for each server with respect to others.In addition to the weight, endpoint selection is then further refined using random distribution based on weight. 





Round Robin

Camel 1.x behavior
The round robin load balancer can actually be used to failover with Camel 1.x. This is no longer possible in Camel 2.x as the underlying Error Handler foundation has been significantly overhauled in Camel 2.x. Frankly the round robin load balancer in Camel 1.x was not thought to be used in a failover scenario.

Camel 2.x behavior
The round robin load balancer is not meant to work with failover, for that you should use the dedicated failover load balancer. The round robin load balancer will only change to next endpoint per message.

The round robin load balancer is statefull as it keeps state which endpoint to use next time.

Using the Fluent Builders

from("direct:start").loadBalance().
roundRobin().to("mock:x", "mock:y", "mock:z");



Using the Spring configuration


"camel" xmlns="http://camel.apache.org/schema/spring">
  
"direct:start"/>


"mock:x"/>
"mock:y"/>   
"mock:z"/> 

  




So the above example will load balance requests from direct:start to one of the available mock endpoint instances, in this case using a round robbin policy.
For further examples of this pattern in use you could look at the junit test case

Failover
Available as of Camel 2.0
The failover load balancer is capable of trying the next processor in case an Exchange failed with an exception during processing.
You can configure the failover with a list of specific exception to only failover. If you do not specify any exceptions it will failover over any exceptions. It uses the same strategy for matching exceptions as the Exception Clause does for the onException.

It has the following options:



 Option 
 Type 
 Default 
 Description 


 inheritErrorHandler 
 boolean 
 true 
 Camel 2.3: Whether or not the Error Handler configured on the route should be used or not. You can disable it if you want the failover to trigger immediately and failover to the next endpoint. On the other hand if you have this option enabled, then Camel will first let the Error Handler try to process the message. The Error Handler may have been configured to redelivery and use delays between attempts. If you have enabled a number of redeliveries then Camel will try to redeliver to the same endpoint, and only failover to the next endpoint, when the Error Handler is exhausted. 


 maximumFailoverAttempts 
 int 
 -1 
 Camel 2.3: A value to indicate after X failver attempts we should exhaust (give up). Use -1 to indicate newer give up and always try to failover. Use 0 to newer failover. And use e.g. 3 to failover at most 3 times before giving up. This option can be used whether or not round robin is enabled or not. 


 roundRobin 
 boolean 
 false 
 Camel 2.3: Whether or not the failover load balancer should operate in round robin mode or not. If not, then it will always start from the first endpoint when a new message is to be processed. In other words it restart from the top for every message. If round robin is enabled, then it keeps state and will continue with the next endpoint in a round robin fashion. When using round robin it will not stick to last known good endpoint, it will always

[CONF] Apache Camel > Load Balancer

2010-10-25 Thread confluence







Load Balancer
Page edited by Ashwin Karpe


 Changes (1)
 



...
{code}  
* As of Camel 2.6* 
 An example using Java DSL: 
...

Full Content

Load Balancer

The Load Balancer Pattern allows you to delegate to one of a number of endpoints using a variety of different load balancing policies.

Build in load balancing policies

Camel has out of the box the following policies:



 Policy 
 Description 


 Round Robin 
 The exchanges is selected in a round robin fashion. This is a well known and classic policy. This spreads the load even. 


 Random 
 A random endpoint is selected for each exchange 


 Sticky 
 Sticky load balancing using an _expression_ to calculate a correlation key to perform the sticky load balancing; rather like jsessionid in the web or JMSXGroupID in JMS. 


 Topic 
 Topic which sends to all destinations (rather like JMS Topics) 


 Failover 
 Camel 2.0: In case of failures the exchange is tried on the next endpoint. 


 Weighted Round-Robin 
 Camel 2.5: The weighted load balancing policy allows you to specify a processing load distribution ratio for each server with respect to others.In addition to the weight, endpoint selection is then further refined using round-robin distribution based on weight. 


 Weighted Random 
 Camel 2.5: The weighted load balancing policy allows you to specify a processing load distribution ratio for each server with respect to others.In addition to the weight, endpoint selection is then further refined using random distribution based on weight. 





Round Robin

Camel 1.x behavior
The round robin load balancer can actually be used to failover with Camel 1.x. This is no longer possible in Camel 2.x as the underlying Error Handler foundation has been significantly overhauled in Camel 2.x. Frankly the round robin load balancer in Camel 1.x was not thought to be used in a failover scenario.

Camel 2.x behavior
The round robin load balancer is not meant to work with failover, for that you should use the dedicated failover load balancer. The round robin load balancer will only change to next endpoint per message.

The round robin load balancer is statefull as it keeps state which endpoint to use next time.

Using the Fluent Builders

from("direct:start").loadBalance().
roundRobin().to("mock:x", "mock:y", "mock:z");



Using the Spring configuration


"camel" xmlns="http://camel.apache.org/schema/spring">
  
"direct:start"/>


"mock:x"/>
"mock:y"/>   
"mock:z"/> 

  




So the above example will load balance requests from direct:start to one of the available mock endpoint instances, in this case using a round robbin policy.
For further examples of this pattern in use you could look at the junit test case

Failover
Available as of Camel 2.0
The failover load balancer is capable of trying the next processor in case an Exchange failed with an exception during processing.
You can configure the failover with a list of specific exception to only failover. If you do not specify any exceptions it will failover over any exceptions. It uses the same strategy for matching exceptions as the Exception Clause does for the onException.

It has the following options:



 Option 
 Type 
 Default 
 Description 


 inheritErrorHandler 
 boolean 
 true 
 Camel 2.3: Whether or not the Error Handler configured on the route should be used or not. You can disable it if you want the failover to trigger immediately and failover to the next endpoint. On the other hand if you have this option enabled, then Camel will first let the Error Handler try to process the message. The Error Handler may have been configured to redelivery and use delays between attempts. If you have enabled a number of redeliveries then Camel will try to redeliver to the same endpoint, and only failover to the next endpoint, when the Error Handler is exhausted. 


 maximumFailoverAttempts 
 int 
 -1 
 Camel 2.3: A value to indicate after X failver attempts we should exhaust (give up). Use -1 to indicate newer give up and always try to failover. Use 0 to newer failover. And use e.g. 3 to failover at most 3 times before giving up. This option can be used whether or not round robin is enabled or not. 


 roundRobin 
 boolean 
 false 
 Camel 2.3: Whether or not the failover load balancer should operate in round robin mode or not. If not, then it will always start from the first endpoint when a new message is to be processed. In other words it restart from the top for every message. If round robin is enabled, then it keeps state and will continue with the next endpoint in a round robin fashion. When using round robin it will not stick to last known good endpoint, it will always pick the next endpoint to use. 





[CONF] Apache Camel > Load Balancer

2010-10-25 Thread confluence







Load Balancer
Page edited by Ashwin Karpe


 Changes (5)
 



...
| [Topic|http://camel.apache.org/maven/camel-2.2.0/camel-core/apidocs/org/apache/camel/processor/loadbalancer/TopicLoadBalancer.html] | Topic which sends to all destinations (rather like JMS Topics) | | [Failover|http://camel.apache.org/maven/camel-2.2.0/camel-core/apidocs/org/apache/camel/processor/loadbalancer/FailOverLoadBalancer.html] | *Camel 2.0:* In case of failures the exchange is tried on the next endpoint. | 
| [Weighted Round-Robin|http://camel.apache.org/maven/camel-2.2.0/camel-core/apidocs/org/apache/camel/processor/loadbalancer/FailOverLoadBalancer.html] | *Camel 2.5:* The weighted load balancing policy allows you to specify a processing load distribution ratio for each server with respect to others.In addition to the weight, endpoint selection is then further refined using *round-robin* distribution based on weight. | | [Weighted Random|] | *Camel 2.5:* The weighted load balancing policy allows you to specify a processing load distribution ratio for each server with respect to others.In addition to the weight, endpoint selection is then further refined using *random* distribution based on weight. | 
 h3. Round Robin 
...
 An example using Java DSL: 
{code:java} 
ArrayList distributionRatio = new ArrayList(); distributionRatio.add(4); 
...
 And the same example using Spring XML: 
{code:xml} 

...
 An example using Java DSL: 
{code:java} 
// round-robin from("direct:start") 
...
 And the same example using Spring XML: 
{code:xml} 

...

Full Content

Load Balancer

The Load Balancer Pattern allows you to delegate to one of a number of endpoints using a variety of different load balancing policies.

Build in load balancing policies

Camel has out of the box the following policies:



 Policy 
 Description 


 Round Robin 
 The exchanges is selected in a round robin fashion. This is a well known and classic policy. This spreads the load even. 


 Random 
 A random endpoint is selected for each exchange 


 Sticky 
 Sticky load balancing using an _expression_ to calculate a correlation key to perform the sticky load balancing; rather like jsessionid in the web or JMSXGroupID in JMS. 


 Topic 
 Topic which sends to all destinations (rather like JMS Topics) 


 Failover 
 Camel 2.0: In case of failures the exchange is tried on the next endpoint. 


 Weighted Round-Robin 
 Camel 2.5: The weighted load balancing policy allows you to specify a processing load distribution ratio for each server with respect to others.In addition to the weight, endpoint selection is then further refined using round-robin distribution based on weight. 


 Weighted Random 
 Camel 2.5: The weighted load balancing policy allows you to specify a processing load distribution ratio for each server with respect to others.In addition to the weight, endpoint selection is then further refined using random distribution based on weight. 





Round Robin

Camel 1.x behavior
The round robin load balancer can actually be used to failover with Camel 1.x. This is no longer possible in Camel 2.x as the underlying Error Handler foundation has been significantly overhauled in Camel 2.x. Frankly the round robin load balancer in Camel 1.x was not thought to be used in a failover scenario.

Camel 2.x behavior
The round robin load balancer is not meant to work with failover, for that you should use the dedicated failover load balancer. The round robin load balancer will only change to next endpoint per message.

The round robin load balancer is statefull as it keeps state which endpoint to use next time.

Using the Fluent Builders

from("direct:start").loadBalance().
roundRobin().to("mock:x", "mock:y", "mock:z");



Using the Spring configuration


"camel" xmlns="http://camel.apache.org/schema/spring">
  
"direct:start"/>


"mock:x"/>
"mock:y"/>   
"mock:z"/> 

  




So the above example will load balance requests from direct:start to one of the available mock endpoint instances, in this case using a round robbin policy.
For further examples of this pattern in use you could look at the junit test case

Failover
Available as of Camel 2.0
The failover load balancer is capable of trying the next processor in case an Exchange failed with an exception during processing.
You can configure the failover with a list of specific exception to only failover. If you do not specify any exceptions it will failover over any exceptions. It uses the same strategy for matchi

[CONF] Apache Camel > Load Balancer

2010-10-25 Thread confluence







Load Balancer
Page edited by Ashwin Karpe


 Changes (8)
 



...
Camel has out of the box the following policies: || Policy || Description || 
| [Round Robin|http://camel.apache.org/maven/camel-2.2.0/camel-core/apidocs/org/apache/camel/processor/loadbalancer/RoundRobinLoadBalancer.html] | The exchanges is selected in a round robin fashion. This is a well known and classic policy. This spreads the load even. | 
| [Random|http://camel.apache.org/maven/camel-core/apidocs/org/apache/camel/processor/loadbalancer/RandomLoadBalancer.html] | A random endpoint is selected for each exchange | 
| [Sticky|http://camel.apache.org/maven/camel-2.2.0/camel-core/apidocs/org/apache/camel/processor/loadbalancer/StickyLoadBalancer.html] | Sticky load balancing using an _expression_ to calculate a correlation key to perform the sticky load balancing; rather like jsessionid in the web or JMSXGroupID in JMS. | 
| [Topic|http://camel.apache.org/maven/camel-2.2.0/camel-core/apidocs/org/apache/camel/processor/loadbalancer/TopicLoadBalancer.html] | Topic which sends to all destinations (rather like JMS Topics) | 
| [Failover|http://camel.apache.org/maven/camel-2.2.0/camel-core/apidocs/org/apache/camel/processor/loadbalancer/FailOverLoadBalancer.html] | *Camel 2.0:* In case of failures the exchange is tried on the next endpoint. | 
| [Weighted Round-Robin|http://camel.apache.org/maven/camel-2.2.0/camel-core/apidocs/org/apache/camel/processor/loadbalancer/FailOverLoadBalancer.html] | *Camel 2.5:* The weighted load balancing policy allows you to specify a processing load distribution ratio for each server with respect to others.In addition to the weight, endpoint selection is then further refined using *round-robin* distribution based on weight. | | [Weighted Random|] | *Camel 2.5:* The weighted load balancing policy allows you to specify a processing load distribution ratio for each server with respect to others.In addition to the weight, endpoint selection is then further refined using *random* distribution based on weight. | 
 h3. Round Robin 
...
 h4. Using Weighted round-robin & random load balancing 
* In Camel 2.5 
*In Camel 2.5* 
An example using Java DSL: {code} 
...
{code}  
* As of Camel 2.6* 
An example using Java DSL: {code} 
...

Full Content

Load Balancer

The Load Balancer Pattern allows you to delegate to one of a number of endpoints using a variety of different load balancing policies.

Build in load balancing policies

Camel has out of the box the following policies:



 Policy 
 Description 


 Round Robin 
 The exchanges is selected in a round robin fashion. This is a well known and classic policy. This spreads the load even. 


 Random 
 A random endpoint is selected for each exchange 


 Sticky 
 Sticky load balancing using an _expression_ to calculate a correlation key to perform the sticky load balancing; rather like jsessionid in the web or JMSXGroupID in JMS. 


 Topic 
 Topic which sends to all destinations (rather like JMS Topics) 


 Failover 
 Camel 2.0: In case of failures the exchange is tried on the next endpoint. 


 Weighted Round-Robin 
 Camel 2.5: The weighted load balancing policy allows you to specify a processing load distribution ratio for each server with respect to others.In addition to the weight, endpoint selection is then further refined using round-robin distribution based on weight. 


 [Weighted Random|] 
 Camel 2.5: The weighted load balancing policy allows you to specify a processing load distribution ratio for each server with respect to others.In addition to the weight, endpoint selection is then further refined using random distribution based on weight. 





Round Robin

Camel 1.x behavior
The round robin load balancer can actually be used to failover with Camel 1.x. This is no longer possible in Camel 2.x as the underlying Error Handler foundation has been significantly overhauled in Camel 2.x. Frankly the round robin load balancer in Camel 1.x was not thought to be used in a failover scenario.

Camel 2.x behavior
The round robin load balancer is not meant to work with failover, for that you should use the dedicated failover load balancer. The round robin load balancer will only change to next endpoint per message.

The round robin load balancer is statefull as it keeps state which endpoint to use next time.

Using the Fluent Builders

from("direct:start").loadBalance().
roundRobin().to("mock:x", "mock:y", "mock:z");



Using the Spring configuration


"camel" xmlns="http://camel.apache.org/schema/spring">
  
"direct:start"/>


"mock:x"/>

[CONF] Apache Camel > Load Balancer

2010-10-25 Thread confluence







Load Balancer
Page edited by Ashwin Karpe


 Changes (1)
 



...
{tip}  
h3. Weighted Round-Robin and Random Load Balancing *Available as of Camel 2.5*  In many enterprise environments where server nodes of unequal processing power & performance characteristics are utilized to host services and processing endpoints, it is frequently necessary to distribute processing load based on their individual server capabilities so that some endpoints are not unfairly burdened with requests. Obviously simple round-robin or random load balancing do not alleviate problems of this nature. A Weighted Round-Robin and/or Weighted Random load balancer can be used to address this problem.  The weighted load balancing policy allows you to specify a processing load distribution ratio for each server with respect to others. You can specify this as a positive processing weight for each server. A larger number indicates that the server can handle a larger load. The weight is utilized to determine the payload distribution ratio to different processing endpoints with respect to others.  {tip:title=Disabled inheritErrorHandler} As of Camel 2.6, the Weighted Load balancer usage has been further simplified, there is no need to send in distributionRatio as a List. It can be simply sent as a delimited String of integer weights separated by a delimiter of choice. {tip}  The parameters that can be used are *In Camel 2.5* || Option || Type || Default || Description || | roundRobin | boolean | false | The default value for round-robin is false. In the absence of this setting or parameter the load balancing algorithm used is random. | distributionRatio | List | none | The distributionRatio is a list consisting on integer weights passed in as a parameter. The distributionRatio must match the number of endpoints and/or processors specified in the load balancer list. In Camel 2.5 if endpoints do not match ratios, then a best effort distribution is attempted. |  *Available In Camel 2.6* || Option || Type || Default || Description || | roundRobin | boolean | false | The default value for round-robin is false. In the absence of this setting or parameter the load balancing algorithm used is random. | distributionRatio | String | none | The distributionRatio is a delimited String consisting on integer weights separated by delimiters for example "2:3:5". The distributionRatio must match the number of endpoints and/or processors specified in the load balancer list. | | distributionRatioDelimiter | String | : | The distributionRatioDelimiter is the delimiter used to specify the distributionRatio. If this attribute is not specified a default delimiter ":" is expected as the delimiter used for specifying the distributionRatio. |  h4. Using Weighted round-robin & random load balancing * In Camel 2.5 An example using Java DSL: {code} ArrayList distributionRatio = new ArrayList(); distributionRatio.add(4); distributionRatio.add(2); distributionRatio.add(1);  // round-robin from("direct:start") .loadBalance().weighted(true, distributionRatio) .to("mock:x", "mock:y", "mock:z");  //random from("direct:start") .loadBalance().weighted(false, distributionRatio) .to("mock:x", "mock:y", "mock:z"); {code}  And the same example using Spring XML: {code}  {code}  * As of Camel 2.6 An example using Java DSL: {code} // round-robin from("direct:start") .loadBalance().weighted(true, "4:2:1") .to("mock:x", "mock:y", "mock:z");  //random from("direct:start") .loadBalance().weighted(false, "4,2,1", ",") .to("mock:x", "mock:y", "mock:z"); {code}  And the same example using Spring XML: {code}  {code}  h4. Using this Pattern 
{include:Using This Pattern} 

Full Content

Load Balancer

The Load Balancer Pattern allows you to delegate to one of a number of endpoints using a variety of different load balancing policies.

Build in load balancing policies

Camel has out of the box the following policies:



 Policy 
 Description 


 Round Robin 
 The exchanges is selected in a round robin fashion. This is a well known and classic policy. This spreads the load even. 


 Random 
 A random endpoint is selected for each exchange 


 Sticky 
 Sticky load balancing using an _expression_ to calculate a correlation key to perform the sticky load balancing; rather like jsessionid in the web or JMSXGroupID in JMS. 


 Topic 
 Topic which sends to all destinations (rather like JMS Topics) 


 Failover 
 Camel 2.0: In case of failures the exchange is tried on the next endpoint. 





Round Robin

Camel 1.x behavior
The round robin load balancer can actually be used to failover with Camel 1.x. This is

[CONF] Apache Camel > Load Balancer

2010-03-10 Thread confluence







 Load Balancer
 Page edited by Claus Ibsen

 
  
 
 Load Balancer

The Load Balancer Pattern allows you to delegate to one of a number of endpoints using a variety of different load balancing policies.

Build in load balancing policies

Camel has out of the box the following policies:


 Policy 
 Description 


 Round Robin 
 The exchanges is selected in a round robin fashion. This is a well known and classic policy. This spreads the load even. 


 Random 
 A random endpoint is selected for each exchange 


 Sticky 
 Sticky load balancing using an _expression_ to calculate a correlation key to perform the sticky load balancing; rather like jsessionid in the web or JMSXGroupID in JMS. 


 Topic 
 Topic which sends to all destinations (rather like JMS Topics) 


 Failover 
 Camel 2.0: In case of failures the exchange is tried on the next endpoint. 



Round Robin

Camel 1.x behavior
The round robin load balancer can actually be used to failover with Camel 1.x. This is no longer possible in Camel 2.x as the underlying Error Handler foundation has been significantly overhauled in Camel 2.x. Frankly the round robin load balancer in Camel 1.x was not thought to be used in a failover scenario.

Camel 2.x behavior
The round robin load balancer is not meant to work with failover, for that you should use the dedicated failover load balancer. The round robin load balancer will only change to next endpoint per message.

The round robin load balancer is statefull as it keeps state which endpoint to use next time.

Using the Fluent Builders

from("direct:start").loadBalance().
roundRobin().to("mock:x", "mock:y", "mock:z");



Using the Spring configuration


"camel" xmlns="http://camel.apache.org/schema/spring">
  
"direct:start"/>


"mock:x"/>
"mock:y"/>   
"mock:z"/> 

  




So the above example will load balance requests from direct:start to one of the available mock endpoint instances, in this case using a round robbin policy.
For further examples of this pattern in use you could look at the junit test case

Failover
Available as of Camel 2.0
The failover load balancer is capable of trying the next processor in case an Exchange failed with an exception during processing.
You can configure the failover with a list of specific exception to only failover. If you do not specify any exceptions it will failover over any exceptions. It uses the same strategy for matching exceptions as the Exception Clause does for the onException.

It has the following options:


 Option 
 Type 
 Default 
 Description 


 inheritErrorHandler 
 boolean 
 true 
 Camel 2.3: Whether or not the Error Handler configured on the route should be used or not. You can disable it if you want the failover to trigger immediately and failover to the next endpoint. On the other hand if you have this option enabled, then Camel will first let the Error Handler try to process the message. The Error Handler may have been configured to redelivery and use delays between attempts. If you have enabled a number of redeliveries then Camel will try to redeliver to the same endpoint, and only failover to the next endpoint, when the Error Handler is exhausted. 


 maximumFailoverAttempts 
 int 
 -1 
 Camel 2.3: A value to indicate after X failver attempts we should exhaust (give up). Use -1 to indicate newer give up and always try to failover. Use 0 to newer failover. And use e.g. 3 to failover at most 3 times before giving up. This option can be used whether or not round robin is enabled or not. 


 roundRobin 
 boolean 
 false 
 Camel 2.3: Whether or not the failover load balancer should operate in round robin mode or not. If not, then it will always start from the first endpoint when a new message is to be processed. In other words it restart from the top for every message. If round robin is enabled, then it keeps state and will continue with the next endpoint in a round robin fashion. When using round robin it will not stick to last known good endpoint, it will always pick the next endpoint to use. 



Camel 2.2 or older behavior
The current implement of failover load balancer is a simple logic which always tries the first endpoint, and in case of an exception being thrown it tries the next in the list, and so forth. It has no state, and the next message will thus always start with the first endpoint.

Camel 2.3 onwards behavior
The failover load balancer now supports round robin mode, which allows you to failover in a round robin fashion. See the roundRobin option.

Redelivery must be enabledIn Camel 2.2 or older the failover load balancer requires you have enabled Camel Error Handler to use redelivery. In Camel 2.3 onwards this is not required as such, as you can mix and match. See the inheritErrorHandler option.

Here is a sample to failover only if a IOException related exception was thrown:

from("direct:start")
// here w

[CONF] Apache Camel > Load Balancer

2010-03-10 Thread confluence







 Load Balancer
 Page edited by Claus Ibsen

 
  
 
 Load Balancer

The Load Balancer Pattern allows you to delegate to one of a number of endpoints using a variety of different load balancing policies.

Build in load balancing policies

Camel has out of the box the following policies:


 Policy 
 Description 


 Round Robin 
 The exchanges is selected in a round robin fashion. This is a well known and classic policy. This spreads the load even. 


 Random 
 A random endpoint is selected for each exchange 


 Sticky 
 Sticky load balancing using an _expression_ to calculate a correlation key to perform the sticky load balancing; rather like jsessionid in the web or JMSXGroupID in JMS. 


 Topic 
 Topic which sends to all destinations (rather like JMS Topics) 


 Failover 
 Camel 2.0: In case of failures the exchange is tried on the next endpoint. 



Round Robin

Camel 1.x behavior
The round robin load balancer can actually be used to failover with Camel 1.x. This is no longer possible in Camel 2.x as the underlying Error Handler foundation has been significantly overhauled in Camel 2.x. Frankly the round robin load balancer in Camel 1.x was not thought to be used in a failover scenario.

Camel 2.x behavior
The round robin load balancer is not meant to work with failover, for that you should use the dedicated failover load balancer. The round robin load balancer will only change to next endpoint per message.

The round robin load balancer is statefull as it keeps state which endpoint to use next time.

Using the Fluent Builders

from("direct:start").loadBalance().
roundRobin().to("mock:x", "mock:y", "mock:z");



Using the Spring configuration


"camel" xmlns="http://camel.apache.org/schema/spring">
  
"direct:start"/>


"mock:x"/>
"mock:y"/>   
"mock:z"/> 

  




So the above example will load balance requests from direct:start to one of the available mock endpoint instances, in this case using a round robbin policy.
For further examples of this pattern in use you could look at the junit test case

Failover
Available as of Camel 2.0
The failover load balancer is capable of trying the next processor in case an Exchange failed with an exception during processing.
You can configure the failover with a list of specific exception to only failover. If you do not specify any exceptions it will failover over any exceptions. It uses the same strategy for matching exceptions as the Exception Clause does for the onException.

It has the following options:


 Option 
 Type 
 Default 
 Description 


 inheritErrorHandler 
 boolean 
 true 
 Camel 2.3: Whether or not the Error Handler configured on the route should be used or not. You can disable it if you want the failover to trigger immediately and failover to the next endpoint. On the other hand if you have this option enabled, then Camel will first let the Error Handler try to process the message. The Error Handler may have been configured to redelivery and use delays between attempts. If you have enabled a number of redeliveries then Camel will try to redeliver to the same endpoint, and only failover to the next endpoint, when the Error Handler is exhausted. 


 maximumFailoverAttempts 
 int 
 -1 
 Camel 2.3: A value to indicate after X failver attempts we should exhaust (give up). Use -1 to indicate newer give up and always try to failover. Use 0 to newer failover. And use e.g. 3 to failover at most 3 times before giving up. This option can be used whether or not round robin is enabled or not. 


 roundRobin 
 boolean 
 false 
 Camel 2.3: Whether or not the failover load balancer should operate in round robin mode or not. If not, then it will always start from the first endpoint when a new message is to be processed. In other words it restart from the top for every message. If round robin is enabled, then it keeps state and will continue with the next endpoint in a round robin fashion. When using round robin it will not stick to last known good endpoint, it will always pick the next endpoint to use. 



Camel 2.2 or older behavior
The current implement of failover load balancer is a simple logic which always tries the first endpoint, and in case of an exception being thrown it tries the next in the list, and so forth. It has no state, and the next message will thus always start with the first endpoint.

Camel 2.3 onwards behavior
The failover load balancer now supports round robin mode, which allows you to failover in a round robin fashion. See the roundRobin option.

Redelivery must be enabledIn Camel 2.2 or older the failover load balancer requires you have enabled Camel Error Handler to use redelivery. In Camel 2.3 onwards this is not required as such, as you can mix and match. See the inheritErrorHandler option.

Here is a sample to failover only if a IOException related exception was thrown:

from("direct:start")
// here w

[CONF] Apache Camel > Load Balancer

2010-03-08 Thread confluence







 Load Balancer
 Page edited by Claus Ibsen

 
  
 
 Load Balancer

The Load Balancer Pattern allows you to delegate to one of a number of endpoints using a variety of different load balancing policies.

Build in load balancing policies

Camel has out of the box the following policies:


 Policy 
 Description 


 Round Robin 
 The exchanges is selected in a round robin fashion. This is a well known and classic policy. This spreads the load even. 


 Random 
 A random endpoint is selected for each exchange 


 Sticky 
 Sticky load balancing using an _expression_ to calculate a correlation key to perform the sticky load balancing; rather like jsessionid in the web or JMSXGroupID in JMS. 


 Topic 
 Topic which sends to all destinations (rather like JMS Topics) 


 Failover 
 Camel 2.0: In case of failures the exchange is tried on the next endpoint. 



Round Robin
Using the Fluent Builders

from("direct:start").loadBalance().
roundRobin().to("mock:x", "mock:y", "mock:z");



Using the Spring configuration


"roundRobinRef" class="org.apache.camel.processor.loadbalancer.RoundRobinLoadBalancer" />
  "camel" xmlns="http://camel.apache.org/schema/spring">

  "direct:start"/>
  "roundRobinRef">
  "mock:x"/>
  "mock:y"/>   
  "mock:z"/>  
  

  



or



"camel" xmlns="http://camel.apache.org/schema/spring">
  
"direct:start"/>

  
"mock:x"/>
"mock:y"/>   
"mock:z"/> 

  




So the above example will load balance requests from direct:start to one of the available mock endpoint instances, in this case using a round robbin policy.
For further examples of this pattern in use you could look at the junit test case

Failover
Available as of Camel 2.0
The failover load balancer is capable of trying the next processor in case an Exchange failed with an exception during processing.
You can configure the failover with a list of specific exception to only failover. If you do not specify any exceptions it will failover over any exceptions. It uses the same strategy for matching exceptions as the Exception Clause does for the onException.

The current implement of failover load balancer is a simple logic which always tries the first endpoint, and in case of an exception being thrown it tries the next in the list, and so forth. It has no state, and the next message will thus always start with the first endpoint.

Redelivery must be enabledThe failover load balancer requires you have enabled Camel Error Handler to use redelivery. By default Camel does not do this.

Here is a sample to failover only if a IOException related exception was thrown:

from("direct:start")
// here we will load balance if IOException was thrown
// any other kind of exception will result in the Exchange as failed
// to failover over any kind of exception we can just omit the exception
// in the failOver DSL
.loadBalance().failover(IOException.class)
.to("direct:x", "direct:y", "direct:z");

 

You can specify multiple exceptions to failover as the option is varargs, for instance:


// enable redelivery so failover can react
errorHandler(defaultErrorHandler().maximumRedeliveries(5));

from("direct:foo").
loadBalance().failover(IOException.class, MyOtherException.class)
.to("direct:a", "direct:b");



Using failover in Spring DSL
Failover can also be used from Spring DSL and you configure it as:


   "myErrorHandler">
  "direct:foo"/>
  
  
  java.io.IOException
  com.mycompany.MyOtherException
  
  "direct:a"/>
  "direct:b"/>
  




Using This Pattern

If you would like to use this EIP Pattern then please read the Getting Started, you may also find the Architecture useful particularly the description of Endpoint and URIs. Then you could try out some of the Examples first before trying this pattern out.
 
 
   
Change Notification Preferences
   

   View Online
   |
   View Change
  |
   Add Comment









[CONF] Apache Camel > Load Balancer

2010-03-08 Thread confluence







 Load Balancer
 Page edited by Claus Ibsen

 
  
 
 Load Balancer

The Load Balancer Pattern allows you to delegate to one of a number of endpoints using a variety of different load balancing policies.

Build in load balancing policies

Camel has out of the box the following policies:


 Policy 
 Description 


 Round Robin 
 The exchanges is selected in a round robin fashion. This is a well known and classic policy. This spreads the load even. 


 Random 
 A random endpoint is selected for each exchange 


 Sticky 
 Sticky load balancing using an _expression_ to calculate a correlation key to perform the sticky load balancing; rather like jsessionid in the web or JMSXGroupID in JMS. 


 Topic 
 Topic which sends to all destinations (rather like JMS Topics) 


 Failover 
 Camel 2.0: In case of failures the exchange is tried on the next endpoint. 



Round Robin
Using the Fluent Builders

from("direct:start").loadBalance().
roundRobin().to("mock:x", "mock:y", "mock:z");



Using the Spring configuration


"roundRobinRef" class="org.apache.camel.processor.loadbalancer.RoundRobinLoadBalancer" />
  "camel" xmlns="http://camel.apache.org/schema/spring">

  "direct:start"/>
  "roundRobinRef">
  "mock:x"/>
  "mock:y"/>   
  "mock:z"/>  
  

  



or



"camel" xmlns="http://camel.apache.org/schema/spring">
  
"direct:start"/>

  
"mock:x"/>
"mock:y"/>   
"mock:z"/> 

  




So the above example will load balance requests from direct:start to one of the available mock endpoint instances, in this case using a round robbin policy.
For further examples of this pattern in use you could look at the junit test case

Failover
Available as of Camel 2.0
The failover load balancer is capable of trying the next processor in case an Exchange failed with an exception during processing.
You can configure the failover with a list of specific exception to only failover. If you do not specify any exceptions it will failover over any exceptions. It uses the same strategy for matching exceptions as the Exception Clause does for the onException.

Redelivery must be enabledThe failover load balancer requires you have enabled Camel Error Handler to use redelivery. By default Camel does not do this.

Here is a sample to failover only if a IOException related exception was thrown:

from("direct:start")
// here we will load balance if IOException was thrown
// any other kind of exception will result in the Exchange as failed
// to failover over any kind of exception we can just omit the exception
// in the failOver DSL
.loadBalance().failover(IOException.class)
.to("direct:x", "direct:y", "direct:z");

 

You can specify multiple exceptions to failover as the option is varargs, for instance:


// enable redelivery so failover can react
errorHandler(defaultErrorHandler().maximumRedeliveries(5));

from("direct:foo").
loadBalance().failover(IOException.class, MyOtherException.class)
.to("direct:a", "direct:b");



Using failover in Spring DSL
Failover can also be used from Spring DSL and you configure it as:


   "myErrorHandler">
  "direct:foo"/>
  
  
  java.io.IOException
  com.mycompany.MyOtherException
  
  "direct:a"/>
  "direct:b"/>
  




Using This Pattern

If you would like to use this EIP Pattern then please read the Getting Started, you may also find the Architecture useful particularly the description of Endpoint and URIs. Then you could try out some of the Examples first before trying this pattern out.
 
 
   
Change Notification Preferences
   

   View Online
   |
   View Change
  |
   Add Comment









[CONF] Apache Camel: Load Balancer (page edited)

2009-05-17 Thread confluence










Page Edited :
CAMEL :
Load Balancer



 
Load Balancer
has been edited by Claus Ibsen
(May 17, 2009).
 

 
 (View changes)
 

Content:
Load Balancer

The Load Balancer Pattern allows you to delegate to one of a number of endpoints using a variety of different load balancing policies.

Build in load balancing policies

Camel has out of the box the following policies:


 Policy 
 Description 


 Round Robin 
 The exchanges is selected in a round robin fashion. This is a well known and classic policy. This spreads the load even. 


 Random 
 A random endpoint is selected for each exchange 


 Sticky 
 Sticky load balancing using an _expression_ to calculate a correlation key to perform the sticky load balancing; rather like jsessionid in the web or JMSXGroupID in JMS. 


 Topic 
 Topic which sends to all destinations (rather like JMS Topics) 


 Failover 
 Camel 2.0: In case of failures the exchange is tried on the next endpoint. 



Round Robin
Using the Fluent Builders

from("direct:start").loadBalance().
roundRobin().to("mock:x", "mock:y", "mock:z");


Using the Spring configuration

"roundRobinRef" class="org.apache.camel.processor.loadbalancer.RoundRobinLoadBalancer" />
  "camel" xmlns="http://camel.apache.org/schema/spring">

  "direct:start"/>
  "roundRobinRef">
  "mock:x"/>
  "mock:y"/>   
  "mock:z"/>  
  

  


or


"camel" xmlns="http://camel.apache.org/schema/spring">
  
"direct:start"/>

  
"mock:x"/>
"mock:y"/>   
"mock:z"/> 

  



So the above example will load balance requests from direct:start to one of the available mock endpoint instances, in this case using a round robbin policy.
For further examples of this pattern in use you could look at the junit test case

Failover
Available as of Camel 2.0
The failover load balancer is capable of trying the next processor in case an Exchange failed with an exception during processing.
You can configure the failover with a list of specific exception to only failover. If you do not specify any exceptions it will failover over any exceptions. It uses the same strategy for matching exceptions as the Exception Clause does for the onException.

Here is a sample to failover only if a IOException related exception was thrown:

from("direct:start")
// here we will load balance if IOException was thrown
// any other kind of exception will result in the Exchange as failed
// to failover over any kind of exception we can just omit the exception
// in the failOver DSL
.loadBalance().failover(IOException.class)
.to("direct:x", "direct:y", "direct:z");
 

You can specify multiple exceptions to failover as the option is varargs, for instance:

loadBalance().failOver(IOException.class, MyOtherException.class).to("direct:a", "direct:b");


Using failover in Spring DSL
Failover can also be used from Spring DSL and you configure it as:


  
  java.io.IOException
  com.mycompany.MyOtherException
  
  "direct:a"/>
  "direct:b"/>
  


Using This Pattern

If you would like to use this EIP Pattern then please read the Getting Started, you may also find the Architecture useful particularly the description of Endpoint and URIs. Then you could try out some of the Examples first before trying this pattern out.











Powered by
Atlassian Confluence
(Version: 2.2.9 Build:#527 Sep 07, 2006)
-
Bug/feature request

Unsubscribe or edit your notifications preferences








[CONF] Apache Camel: Load Balancer (page edited)

2009-05-17 Thread confluence










Page Edited :
CAMEL :
Load Balancer



 
Load Balancer
has been edited by Claus Ibsen
(May 17, 2009).
 

 
 (View changes)
 

Content:
Load Balancer

The Load Balancer Pattern allows you to delegate to one of a number of endpoints using a variety of different load balancing policies.

Build in load balancing policies

Camel has out of the box the following policies:


 Policy 
 Description 


 Round Robin 
 The exchanges is selected in a round robin fashion. This is a well known and classic policy. This spreads the load even. 


 Random 
 A random endpoint is selected for each exchange 


 Sticky 
 Sticky load balancing using an _expression_ to calculate a correlation key to perform the sticky load balancing; rather like jsessionid in the web or JMSXGroupID in JMS. 


 Topic 
 Topic which sends to all destinations (rather like JMS Topics) 


 Failover 
 Camel 2.0: In case of failures the exchange is tried on the next endpoint. 



Round Robin
Using the Fluent Builders

from("direct:start").loadBalance().
roundRobin().to("mock:x", "mock:y", "mock:z");


Using the Spring configuration

"roundRobinRef" class="org.apache.camel.processor.loadbalancer.RoundRobinLoadBalancer" />
  "camel" xmlns="http://camel.apache.org/schema/spring">

  "direct:start"/>
  "roundRobinRef">
  "mock:x"/>
  "mock:y"/>   
  "mock:z"/>  
  

  


or


"camel" xmlns="http://camel.apache.org/schema/spring">
  
"direct:start"/>

  
"mock:x"/>
"mock:y"/>   
"mock:z"/> 

  



So the above example will load balance requests from direct:start to one of the available mock endpoint instances, in this case using a round robbin policy.
For further examples of this pattern in use you could look at the junit test case

Failover
Available as of Camel 2.0
The failover load balancer is capable of trying the next processor in case an Exchange failed with an exception during processing.
You can configure the failover with a list of specific exception to only failover. If you do not specify any exceptions it will failover over any exceptions. It uses the same strategy for matching exceptions as the Exception Clause does for the onException.

Here is a sample to failover only if a IOException related exception was thrown:

from("direct:start")
// here we will load balance if IOException was thrown
// any other kind of exception will result in the Exchange as failed
// to failover over any kind of exception we can just omit the exception
// in the failOver DSL
.loadBalance().failover(IOException.class)
.to("direct:x", "direct:y", "direct:z");
 


Using This Pattern

If you would like to use this EIP Pattern then please read the Getting Started, you may also find the Architecture useful particularly the description of Endpoint and URIs. Then you could try out some of the Examples first before trying this pattern out.











Powered by
Atlassian Confluence
(Version: 2.2.9 Build:#527 Sep 07, 2006)
-
Bug/feature request

Unsubscribe or edit your notifications preferences








[CONF] Apache Camel: Load Balancer (page edited)

2009-05-14 Thread confluence










Page Edited :
CAMEL :
Load Balancer



 
Load Balancer
has been edited by Claus Ibsen
(May 14, 2009).
 

 
 (View changes)
 

Content:
Load Balancer

The Load Balancer Pattern allows you to delegate to one of a number of endpoints using a variety of different load balancing policies.

Using the Fluent Builders

from("direct:start").loadBalance().
roundRobin().to("mock:x", "mock:y", "mock:z");


Using the Spring configuration

"roundRobinRef" class="org.apache.camel.processor.loadbalancer.RoundRobinLoadBalancer" />
  "camel" xmlns="http://camel.apache.org/schema/spring">

  "direct:start"/>
  "roundRobinRef">
  "mock:x"/>
  "mock:y"/>   
  "mock:z"/>  
  

  


or


"camel" xmlns="http://camel.apache.org/schema/spring">
  
"direct:start"/>

  
"mock:x"/>
"mock:y"/>   
"mock:z"/> 

  




So the above example will load balance requests from direct:start to one of the available mock endpoint instances, in this case using a round robbin policy.
For further examples of this pattern in use you could look at the junit test case

Build in load balancing policies

Camel has out of the box the following policies:


 Policy 
 Description 


 Round Robin 
 The exchanges is selected in a round robin fashion. This is a well known and classic policy. This spreads the load even. 


 Random 
 A random endpoint is selected for each exchange 


 Sticky 
 Sticky load balancing using an _expression_ to calculate a correlation key to perform the sticky load balancing; rather like jsessionid in the web or JMSXGroupID in JMS. 


 Topic 
 Topic which sends to all destinations (rather like JMS Topics) 


 Failover 
 Camel 2.0: In case of failures the exchange is tried on the next endpoint. 



Using This Pattern

If you would like to use this EIP Pattern then please read the Getting Started, you may also find the Architecture useful particularly the description of Endpoint and URIs. Then you could try out some of the Examples first before trying this pattern out.











Powered by
Atlassian Confluence
(Version: 2.2.9 Build:#527 Sep 07, 2006)
-
Bug/feature request

Unsubscribe or edit your notifications preferences