1. Observations Week 4

2. Observe Code Change! Review week plan! Also, a load generator is added to the exercises on Iteration 3 for ‘smoking out’ the exceptions thrown by MongoDB. CS@AUHenrik Bærbak Christensen2

3. -automated ? Automated testing of MongoDB failover? –Shall @Before setup 3 docker mongo instances? No! –1) Manual testing to find integration point failure modes I.e. exceptions thrown by weather service, subscription service, etc., under ‘no connection’, ‘slow response’, … Wrap them in domain exceptions –CaveSlowResponseException, CaveXXXException… –2) Make Saboteur that simulates these events ”on third call, throw a CaveSlowResponseException” –3) (TDD/Develop) the graceful degradation code in the layer above (i.e. the code that calls the integration point) –4) Develop the JUnit test case that exercises all graceful degradation handling code If you did not use TDD in the first place… CS@AUHenrik Bærbak Christensen3

4. Take Small Steps Example: Circuit Breaker –Experience in the CloudCave Code a bit here, there, hm, …, hmmm, big ball of mud  Do Over – and take small steps –What is Circuit Breaker? State Machine Time outWhy not make this work first? –Where is the breaker? StandardServerPlayer? WeatherService? Decorator? Why not make the breaker work first; and then next refactor to a Decorator solution? Clean code that works, but not in that order! CS@AUHenrik Bærbak Christensen4

5. The API trap… Player API/ ‘*** Sorry – weather info …’ WeatherService API Question: –How to communicate breaker ‘Open-State’? ‘*** Sorry – no weather (open circuit) ***’ CS@AUHenrik Bærbak Christensen5

6. Discussion If the breaker is in the StdServerPlayer –No real problem If directly in WeatherService –Mingled responsibilities Or in Decorator around WeatherService –Nice separation of responsibilities There is a ‘return value’ problem –JSON object has no ‘field’ for breaker stuff –Exceptions should not bubble up an answer as part of the ‘message’ field But then we have to cast different exceptions; and StdServerPlayer still contains some of the responsibility CS@AUHenrik Bærbak Christensen6

7. Operation-socket Vision –Reality: up-time is rewarded by customer loyalty –CloudArch tries to mimic reality But –Current ‘crunch’ is pretty static The functional requirements are pretty static –‘Challenging stuff’ cannot be tested by us in prod. –Uncertainties in scoring Digital Ocean stuff, AUIT interruption, … CS@AUHenrik Bærbak Christensen7

8. Operation-socket Last Crunch run –Sept 17 th at 13.00 Stats –14 days of 24 ‘ticks’ Minus 21 ticks during AUIT maintenance window –~ 325 ticks… Scoring –Original: 100 points for 6 weeks => 33 ticks for 2 weeks –Score adjusted:0..32 points CS@AUHenrik Bærbak Christensen8

9. Operation-socket Grade influence –I do not think 3-5 points will influence much –All border cases will be studied! 360 points = 7;361 points = 10 Birte scores 356 points –=> I will look if Birte’s group has less than 32 points in ‘ops-soc’ –If so, I will look into if this is due to ‘issues’ CS@AUHenrik Bærbak Christensen9

10. State Pattern Remember the central two ways –Parametric ”if ( state == BreakerState.OPEN ) {” –State pattern state.retrieveWeatherString() state = state.nextState(); If feeling insecure, pick the parametric one! –State + Decorator is really cool, but requires a very very steady hand! CS@AUHenrik Bærbak Christensen10