http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660Mike, _Nice_ catch http://ayende.com/4069/lying-as-a-valid-coding-pattern#comment12http://ayende.com/4069/lying-as-a-valid-coding-pattern#comment12Thu, 23 Jul 2009 09:03:20 GMTThere's also an insidious bug in your code, which I thought I'd point out because many programmers make the same mistake: by using DateTime.Now, the code can malfunction in the fall when the clock goes back and the circuit breaker will get stuck in the closed state for an hour longer than it should. It's perhaps not a big issue in this case, but one which can cause inexplicable behaviour. Solution: always use DateTime.UtcNow for this. http://ayende.com/4069/lying-as-a-valid-coding-pattern#comment11http://ayende.com/4069/lying-as-a-valid-coding-pattern#comment11Thu, 16 Jul 2009 10:04:14 GMTI can see how the apparent difference in behavior would not occur because of how the class is used in the context of a circuit breaker. My guess is that the MoveToHalfOpenState doesn't need to happen unless someone is attempting a protected action. Also, after moving to the HalfOpenState, the ProtectedCode... of the OpenState class would no longer be called. Just my guess after thinking about it more. http://ayende.com/4069/lying-as-a-valid-coding-pattern#comment10http://ayende.com/4069/lying-as-a-valid-coding-pattern#comment10Wed, 15 Jul 2009 17:29:39 GMTYour code does not work the same. In your implementation, after the protected service was working again and the timeout was up, it would take two calls to the service to get the circuit breaker to actually call the service again. In the original implementation, the circuit breaker would correctly start calling the service again on the first call once the timeout was up. http://ayende.com/4069/lying-as-a-valid-coding-pattern#comment9http://ayende.com/4069/lying-as-a-valid-coding-pattern#comment9Wed, 15 Jul 2009 17:29:24 GMTAlso in the first example the MoveToHalfOpenState is called automatically a certain time after the ctor executes. In the 2nd example MoveToHalfOpenState is only called if the caller explicitly calls ProtectedCodeIsAboutToBeCalled after the timeout. http://ayende.com/4069/lying-as-a-valid-coding-pattern#comment8http://ayende.com/4069/lying-as-a-valid-coding-pattern#comment8Wed, 15 Jul 2009 16:44:42 GMTMy mistake, the second only if not expired http://ayende.com/4069/lying-as-a-valid-coding-pattern#comment7http://ayende.com/4069/lying-as-a-valid-coding-pattern#comment7Wed, 15 Jul 2009 15:53:02 GMTI don't know what a circuit breaker is, but at a glance it would appear the two versions of the code would behave quite differently. In the first, the ProtectedCodeIsAboutToBeCalled method will through an exception regardless of any "timeout". In the second, the exception only occurs if the time has expired. Am I missing something? http://ayende.com/4069/lying-as-a-valid-coding-pattern#comment6http://ayende.com/4069/lying-as-a-valid-coding-pattern#comment6Wed, 15 Jul 2009 15:51:15 GMTTimer or a similar approach is valid, when you do not want to force unwanted side effects of testing if external system is up on your currently executing thread, i.e. UI. If the system is down and timeouts you don't want to wait for like 30 seconds with your UI freezed or web server thread doing nothing but waiting. Going timer + background thread solves this problem by "pinging" external system in the background. http://ayende.com/4069/lying-as-a-valid-coding-pattern#comment5http://ayende.com/4069/lying-as-a-valid-coding-pattern#comment5Wed, 15 Jul 2009 13:22:31 GMT@Ollie Riches it's not a retry-policy at all... the code never retries an operation. If a protected resource is known to have failed X amount of times, it simply fails immediately (which opens the circuit) instead of actually calling the protected resource. http://ayende.com/4069/lying-as-a-valid-coding-pattern#comment4http://ayende.com/4069/lying-as-a-valid-coding-pattern#comment4Wed, 15 Jul 2009 13:02:20 GMTTo me this pattern really isn't a 'circuit breaker' in the true sense of the word it's more of a 'retry policy' - I guess 'circuit breaker' sounds better though ;) But like a circuit breaker it doesn't tell why the problem occurred just that it has... http://ayende.com/4069/lying-as-a-valid-coding-pattern#comment3http://ayende.com/4069/lying-as-a-valid-coding-pattern#comment3Wed, 15 Jul 2009 11:18:00 GMTIt's been over two years since Michael Nygard's excellent Release It! book was published. It's good to see some detailed debate and implementations of this pattern in C#. [ayende.com/.../...g-as-a-valid-coding-pattern.aspx](http://ayende.com/Blog/archive/2009/07/15/lying-as-a-valid-coding-pattern.aspx) [davybrion.com/.../protecting-your-application-f...](http://davybrion.com/blog/2009/07/protecting-your-application-from-remote-problems/) [timross.wordpress.com/.../implementing-the-circ...](http://timross.wordpress.com/2008/02/17/implementing-the-circuit-breaker-pattern-in-c-part-2/) http://ayende.com/4069/lying-as-a-valid-coding-pattern#comment2http://ayende.com/4069/lying-as-a-valid-coding-pattern#comment2Wed, 15 Jul 2009 09:54:45 GMTI guess we should also separate the decision making mechanism from the actual breaker. I mean you caught the exception - how are supposed to know that is caused by the remote service overload? http://ayende.com/4069/lying-as-a-valid-coding-pattern#comment1http://ayende.com/4069/lying-as-a-valid-coding-pattern#comment1Wed, 15 Jul 2009 08:56:03 GMT