Memory Leak Issue with spring-cloud-starter-hystrix and spring-cloud-starter-archaius integration - memory-leaks

Question

We are using spring-cloud-starter-hystrix with spring-cloud-starter-archaius where we are unable to stop the poolingconfigurationSource thread of archaius once the war is un-deployed. But spring-cloud-starter-archaius is working fine without hystrix and thread is stopped once war is un-deployed.

Answer 1

Try reseting Hystrix before the Spring Application shuts down
#EnableCircuitBreaker
#SpringBootApplication
public class Application {
public static void main(String[] args) {
SpringApplication.run(Application.class, args);
}
#PreDestroy
public void cleanUp() {
Hystrix.reset();
}
}

Answer 2

**Issue resolved permanently.**
**There are 2 approach :**
1) Create ContextListener in Servlet and in destroy method , copy below code.
2) If you are using Histrix + Spring Boot + Archaius then on main spring application java file , copy below code in method annonated with #PreDestory annotations.
**Solution :**
try {
if (ConfigurationManager.getConfigInstance() instanceof DynamicConfiguration) {
DynamicConfiguration config = (DynamicConfiguration) ConfigurationManager.getConfigInstance();
config.stopLoading();
} else if (ConfigurationManager.getConfigInstance() instanceof ConcurrentCompositeConfiguration) {
ConcurrentCompositeConfiguration configInst = (ConcurrentCompositeConfiguration) ConfigurationManager
.getConfigInstance();
List<AbstractConfiguration> configs = configInst.getConfigurations();
if (configs != null) {
for (AbstractConfiguration config : configs) {
if (config instanceof DynamicConfiguration) {
((DynamicConfiguration) config).stopLoading();
break;
}
}
}
}
} catch (Exception e) {
e.printStackTrace();
}

Answer 3

both Davin and Ashish Patel are right: there are multiple leaks caused by Spring cloud.
The presence of a some threads named pollingConfigurationSource can be partially fixed by the solution proposed by Davin. You also need to make sure not to have any file named config.properties in your classpath because com.netflix.config.sources.URLConfigurationSource (look in the source for all the cases) will search for common patsh and start an exectutor thread. there are multiple path in the code that causes an executorservice on thread "pollingConfigurationSource" to be started (an not be always stopped). In my case removing "config.properties" solved this leak
The other leak I'm aware of is caused by Hystrix/RjJava. Instead of calling Histrix.reset call rx.schedulers.Schedulers.shutdown(); this will force threads "RxIoScheduler-" to exit.