camel-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Raul Kripalani (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CAMEL-5539) Circuit Breaker EIP
Date Thu, 20 Sep 2012 00:11:07 GMT

    [ https://issues.apache.org/jira/browse/CAMEL-5539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13459237#comment-13459237
] 

Raul Kripalani commented on CAMEL-5539:
---------------------------------------

A few initial thoughts on the design of this new EIP:

* The EIP should wrap around an endpoint or a processor. It's important to cover Processors
too because frequently the access external resources (DBs or callouts to partnerlinks).
* By default, it'll be sensitive to all exceptions, but the user can limit the scope by specifying
what exceptions to cover, using the <exception /> DSL.
* Possible transitions: Closed => Open, Open => HalfOpen, HalfOpen => Open, HalfOpen
=> Closed. The user may configure actions for each transition:
** throw an exception, applicable to Closed => Open, Open => HalfOpen
** invoke another endpoint (e.g. to notify that a transition has happened), or to take an
alternative route, applicable to all transitions
* As David suggests, the algorithm must be pluggable; the strategy interface must be notified
twice: before and after an exchange is processed.

Two options spring to mind with respect to the interaction between the Strategy and the EIP
itself:
# The strategy gets a control class (the circuit breaker itself) via a setter. It must use
this control class to signal when a transition occurs. 'Before' and 'after' callbacks just
to do accountancy. When thresholds are surpassed, the appropriate method in the circuit breaker
must be called to signal the transition.
# 'Before' and 'after' methods return transition enumeration elements to the Circuit Breaker
control class, and the Circuit Breaker decides what to do depending on the transition taken.
A possible transition is "None".
** E.g.: the 'after' method returning Transition.ClosedToOpen means that the failure threshold
was exceeded. From then on, all 'before' invocations would return Transition.None and the
EIP will refrain from sending to the endpoint/processor. When state changes to HalfOpen, the
EIP will continue dispatching to the endpoint. If the endpoint fails again, the 'after' method
should see an Exception in the Exchange and return Transition.Open again, and so the story
goes.

Please feel free to comment to provide your valuable proposals ;)
                
> Circuit Breaker EIP
> -------------------
>
>                 Key: CAMEL-5539
>                 URL: https://issues.apache.org/jira/browse/CAMEL-5539
>             Project: Camel
>          Issue Type: New Feature
>          Components: camel-core, eip
>            Reporter: Claus Ibsen
>            Assignee: Raul Kripalani
>             Fix For: 2.11.0
>
>
> Look at add the circuit breaker EIP to the Camel DSL.
> http://davybrion.com/blog/2008/05/the-circuit-breaker/
> Would need some thoughts for that though. Either as an explicit in the DSL. Or as a interceptor
for sending to an endpoint. As explicit its a kind to the load balancer (in fact it may be
extended upon that). Either the LB selects the intended target, or it select the breaker,
which rejects executing the message.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message