On Sat, Mar 12, 2016 at 6:16 PM, Afkham Azeez <az...@wso2.com> wrote:

> Isabelle & Sanjiva,
>
> http://www.javaworld.com/article/2824163/application-performance/stability-patterns-applied-in-a-restful-architecture.html?page=2
> which Aruna had given as a reference explains circuit breaker on the server
> side. IMO, circuit breaker on both client side & server side are useful
> features in a microservices framework. In fact these are features people
> look for when evaluating microservices frameworks.
>
> Thanks
> Azeez
>
> On Sat, Mar 12, 2016 at 5:11 PM, Isabelle Mauny <isabe...@wso2.com> wrote:
>
>> If an API GW is used to access the microservices , then the circuit
>> breaker pattern would apply at that level, right ?  If the client is a web
>> app directly calling MS (not that this would be a good pattern at all !)
>> then the client is the web app. In any case, they are all clients calling
>> the microservices. So I am not sure about server side either..
>>
>>
>> -------------------------------------------------------------------------------------
>> *Isabelle Mauny*
>> VP, Product Management - WSO2, Inc. - http://wso2.com/
>>
>> On Sat, Mar 12, 2016 at 8:26 AM, Sanjiva Weerawarana <sanj...@wso2.com>
>> wrote:
>>
>>> I don't understand what server side circuit breaker means. How does the
>>> server adjust itself? Where's that bit of logic running?
>>>
>>
Hi Sanjiva,

The breaker will not be enabled by default, if a user want to restrict
requests when the server is continuously returning 5XX status codes, when
the threshold reached the circuit will break for a given timeout value.
After the timeout, the circuit will move to a half-open state and allow
requests to flow, if the preceding requests return success the circuit move
to the closed state. Otherwise move to the open state with the timeout.

The plan is to make it configurable, global and per resource wise.

Regards,
Aruna

>
>>> IMO this is not needed in a container world.
>>>
>>> On Fri, Mar 11, 2016 at 4:38 PM, Afkham Azeez <az...@wso2.com> wrote:
>>>
>>>> Yes, that is client side circuit breaker. What Aruna is implementing is
>>>> server side circuit breaker. Yes, we need both.
>>>>
>>>> On Fri, Mar 11, 2016 at 4:04 PM, Lakmal Warusawithana <lak...@wso2.com>
>>>> wrote:
>>>>
>>>>> Did you looked at [1]
>>>>>
>>>>> Netflix Hystrix <https://github.com/Netflix/Hystrix> is an incredibly
>>>>> useful library for writing code that invokes remote services. Hystrix 
>>>>> times
>>>>> out calls that exceed the specified threshold. It implements a *circuit
>>>>> breaker* pattern, which stops the client from waiting needlessly for
>>>>> an unresponsive service. If the error rate for a service exceeds a
>>>>> specified threshold, Hystrix trips the circuit breaker and all requests
>>>>> will fail immediately for a specified period of time. Hystrix lets you
>>>>> define a fallback action when a request fails, such as reading from a 
>>>>> cache
>>>>> or returning a default value. If you are using the JVM you should
>>>>> definitely consider using Hystrix.
>>>>>
>>>>> [1] https://github.com/Netflix/Hystrix
>>>>>
>>>>> On Fri, Mar 11, 2016 at 2:42 PM, Aruna Karunarathna <ar...@wso2.com>
>>>>> wrote:
>>>>>
>>>>>> Hi Devs,
>>>>>>
>>>>>> *Scenario*
>>>>>>
>>>>>> The deployed services in a MSF4J may fail to serve the requests due
>>>>>> to various factors. e.g,
>>>>>> 1. Less resources in the server.
>>>>>> 2. High Load in the server
>>>>>> 3, Some services take more time to respond etc.
>>>>>>
>>>>>> In this kind of a situation, if the server is getting requests though
>>>>>> there is no resources to serve those requests, and eventually the server
>>>>>> will get unusable.
>>>>>>
>>>>>> *Solution*
>>>>>>
>>>>>> The Circuit Breaker design pattern can save the server from above
>>>>>> scenarios, The typical design can be illustrated as in the following
>>>>>> diagram.
>>>>>>
>>>>>>
>>>>>> So as in the above diagram, when number of failures of a particular
>>>>>> resource exceeds the Max Failure Count, then the state of that resource 
>>>>>> is
>>>>>> moved to the open state with a timeout value (Trip Breaker). At this 
>>>>>> point
>>>>>> the requests coming to the server is routed back without passing the
>>>>>> internal to process further.
>>>>>>
>>>>>> After the timeout has reached, the state is moved to Half-Open state,
>>>>>> and if the consecutive request pass to the server to process (Attempt
>>>>>> Reset), if success then close the circuit (Reset Breaker), If fail then
>>>>>> again move the state to the Open with a timeout value (Trip Breaker).
>>>>>>
>>>>>> Any thoughts, suggestions regarding the above approach?
>>>>>>
>>>>>> References
>>>>>> [1].
>>>>>> http://www.javaworld.com/article/2824163/application-performance/stability-patterns-applied-in-a-restful-architecture.html?page=2
>>>>>> [2].
>>>>>> http://ssagara.blogspot.com/2015/05/timeout-and-circuit-breaker-pattern-in.html
>>>>>> [3]. https://pragprog.com/book/mnee/release-it
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>> Aruna
>>>>>> --
>>>>>>
>>>>>> *Aruna Sujith Karunarathna *
>>>>>> WSO2, Inc | lean. enterprise. middleware.
>>>>>> #20, Palm Grove, Colombo 03, Sri Lanka
>>>>>> Mobile: +94 71 9040362 | Work: +94 112145345
>>>>>> Email: ar...@wso2.com | Web: www.wso2.com
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Architecture mailing list
>>>>>> Architecture@wso2.org
>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Lakmal Warusawithana
>>>>> Director - Cloud Architecture; WSO2 Inc.
>>>>> Mobile : +94714289692
>>>>> Blog : http://lakmalsview.blogspot.com/
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> *Afkham Azeez*
>>>> Director of Architecture; WSO2, Inc.; http://wso2.com
>>>> Member; Apache Software Foundation; http://www.apache.org/
>>>> * <http://www.apache.org/>*
>>>> *email: **az...@wso2.com* <az...@wso2.com>
>>>> * cell: +94 77 3320919 <%2B94%2077%203320919>blog: *
>>>> *http://blog.afkham.org* <http://blog.afkham.org>
>>>> *twitter: **http://twitter.com/afkham_azeez*
>>>> <http://twitter.com/afkham_azeez>
>>>> *linked-in: **http://lk.linkedin.com/in/afkhamazeez
>>>> <http://lk.linkedin.com/in/afkhamazeez>*
>>>>
>>>> *Lean . Enterprise . Middleware*
>>>>
>>>> _______________________________________________
>>>> Architecture mailing list
>>>> Architecture@wso2.org
>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>
>>>>
>>>
>>>
>>> --
>>> Sanjiva Weerawarana, Ph.D.
>>> Founder, CEO & Chief Architect; WSO2, Inc.;  http://wso2.com/
>>> email: sanj...@wso2.com; office: (+1 650 745 4499 | +94  11 214 5345)
>>> x5700; cell: +94 77 787 6880 | +1 408 466 5099; voip: +1 650 265 8311
>>> blog: http://sanjiva.weerawarana.org/; twitter: @sanjiva
>>> Lean . Enterprise . Middleware
>>>
>>> _______________________________________________
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>> _______________________________________________
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> *Afkham Azeez*
> Director of Architecture; WSO2, Inc.; http://wso2.com
> Member; Apache Software Foundation; http://www.apache.org/
> * <http://www.apache.org/>*
> *email: **az...@wso2.com* <az...@wso2.com>
> * cell: +94 77 3320919 <%2B94%2077%203320919>blog: *
> *http://blog.afkham.org* <http://blog.afkham.org>
> *twitter: **http://twitter.com/afkham_azeez*
> <http://twitter.com/afkham_azeez>
> *linked-in: **http://lk.linkedin.com/in/afkhamazeez
> <http://lk.linkedin.com/in/afkhamazeez>*
>
> *Lean . Enterprise . Middleware*
>
> _______________________________________________
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 

*Aruna Sujith Karunarathna *
WSO2, Inc | lean. enterprise. middleware.
#20, Palm Grove, Colombo 03, Sri Lanka
Mobile: +94 71 9040362 | Work: +94 112145345
Email: ar...@wso2.com | Web: www.wso2.com
_______________________________________________
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to