Commits on Dec 15, 2014

1. Race condition exists when constructing a HystrixThreadPool where the… …

   … ThreadPoolExecutor used by HystrixThreadPool.Factory is not the same instance as the one that is associated with the HystrixMetricsPublisherThreadPool.
   
   This causes a disconnect between the ThreadPoolExecutor's metrics and those supplied by HystrixMetricsThreadPool.
   
   Now the ThreadPoolExecutor itself is retrieved from the HystrixMetricsThreadPool object, because it is protected behind the pattern of a ConcurrentMap#putIfAbsent. This seemed much more difficult to do with the ConcurrencyStrategy
   as then any further custom implementations would not have similar concurrency guarantees.
   
   A test has been added to show that the ThreadPoolExecutor construct is indeed correct and the same as the one associated with the metrics publisher. It was a bit difficult to construct a test to prove the bad case and good case at the same time. Once the solution was in place, I had to turn the failing test case into a validation test case.
   
   In addition this exposed some static state that was kept around between some tests that needed to be cleaned up. In particular the HystrixMetricsPublisherFactory has a singleton object that needed to be reset (even though it's a singleton) in order to validate the test. I'm not particularly happy with this approach, so I'd be happy for any help here.
   
   Conflicts:
   	hystrix-core/src/test/java/com/netflix/hystrix/HystrixThreadPoolTest.java

   cgray authored and Matt Jacobs committed Dec 15, 2014
   Configuration menu

   • View commit details
   • Copy full SHA for 585d385
   • Browse repository at this point

   Copy the full SHA

   585d385 View commit details

   Browse the repository at this point in the history