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 <[email protected]> wrote: > I don't understand what server side circuit breaker means. How does the > server adjust itself? Where's that bit of logic running? > > IMO this is not needed in a container world. > > On Fri, Mar 11, 2016 at 4:38 PM, Afkham Azeez <[email protected]> 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 <[email protected]> >> 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 <[email protected]> >>> 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: [email protected] | Web: www.wso2.com >>>> >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> [email protected] >>>> 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: **[email protected]* <[email protected]> >> * 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 >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Sanjiva Weerawarana, Ph.D. > Founder, CEO & Chief Architect; WSO2, Inc.; http://wso2.com/ > email: [email protected]; 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 > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
