You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Bruno P. Kinoshita (JIRA)" <ji...@apache.org> on 2015/05/24 12:05:17 UTC
[jira] [Comment Edited] (LANG-1085) Add a circuit breaker
implementation
[ https://issues.apache.org/jira/browse/LANG-1085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14557668#comment-14557668 ]
Bruno P. Kinoshita edited comment on LANG-1085 at 5/24/15 10:04 AM:
--------------------------------------------------------------------
Hello again Oliver!
Had a look again at the patch today, and I really think making the CircuitBreaker more generic would be a good idea. My goal is to use your CircuitBreaker to create a MemoryCircuitBreaker, as in ElasticSearch. The MemoryCircuitBreaker doesn't need to be reset after a period of time, so it wouldn't fit into the current design of the CircuitBreaker contract.
What do you think of the follow plan:
- Create the following class hierarchy
{noformat}
+--------------+
|CircuitBreaker|
+------+-------+
^
|
|
|
|
+----------+------------+
| AbstractCircuitBreaker|
+----------+------------+
^
|
|
+---------------+----------------+
| |
| |
+---------+---------+ ----------+---------+
|TimedCircuitBreaker| |MemoryCircuitBreaker|
+-------------------+ +--------------------+
{noformat}
- Move the `AtomicReference`'s and the `PropertyChangeSupport` to the abstract circuit breaker
- Move the `Timer`'s to the timed circuit breaker (there is another class [lang] with this prefix)
- Extract a generic contract for the `CircuitBreaker` interface
> I guess such an interface would have methods like open(), close(), isOpen(), isClosed(), checkState(), incrementAndCheckState()
+1 Sounds like good methods for our initial tests :-)
Do you think that makes sense?
was (Author: kinow):
Hello again Oliver!
Had a look again at the patch today, and I really think making the CircuitBreaker more generic would be a good idea. My goal is to use your CircuitBreaker to create a MemoryCircuitBreaker, as in ElasticSearch. The MemoryCircuitBreaker doesn't need to be reset after a period of time, so it wouldn't fit into the current design of the CircuitBreaker contract.
What do you think of the follow plan:
- Create the following class hierarchy
{noformat}
+--------------+
|CircuitBreaker|
+------+-------+
^
|
|
|
|
+----------+------------+
| AbstractCircuitBreaker|
+----------+------------+
^
|
|
+---------------+----------------+
| |
| |
+---------+---------+ ----------+---------+
|TimerCircuitBreaker| |MemoryCircuitBreaker|
+-------------------+ +--------------------+
{noformat}
- Move the `AtomicReference`'s and the `PropertyChangeSupport` to the abstract circuit breaker
- Move the `Timer`'s to the timer circuit breaker
- Extract a generic contract for the `CircuitBreaker` interface
> I guess such an interface would have methods like open(), close(), isOpen(), isClosed(), checkState(), incrementAndCheckState()
+1 Sounds like good methods for our initial tests :-)
Do you think that makes sense?
> Add a circuit breaker implementation
> ------------------------------------
>
> Key: LANG-1085
> URL: https://issues.apache.org/jira/browse/LANG-1085
> Project: Commons Lang
> Issue Type: New Feature
> Components: lang.concurrent.*
> Reporter: Oliver Heger
> Attachments: CircuitBreaker.java, CircuitBreakerTest.java
>
>
> A _circuit breaker_ is a useful component to protect an application against unreliable services or load peaks. A simple implementation could be a good fit for the concurrent package.
> A proposed implementation is attached. Feedback is welcome!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)