spring-cloud-consul: Memory leak with Consul Config Watch
I raised the following issue on Stackoverflow because I was experiencing my Spring Boot app just eating away at the heap
After investigation is appears as though Consul is returning a changing X-Consul-Index header value when requesting KVs that do not exist.
For example http://consul:8500/v1/kv/mio/application,server/?recurse&wait=2s&index=281722, where mio/application,server is the default content and one of the active Spring profiles. 281722 was the index value returned from the previous call, and Consul may now return a completely different value.
A changing X-Consul-Index value causes the Spring Cloud to refresh the context (via org.springframework.cloud.consul.config.ConfigWatch#watchConfigKeyValues), which in turn creates a new instance of org.springframework.cloud.consul.config.ConsulPropertySourceLocator. For whatever reason, the old instance of ConsulPropertySourceLocator aren’t garbage collected, leading to a memory leak.
I’m using Spring Boot c1.3.2.RELEASE, Spring Cloud vBrixton.RC2 and Consul v0.6.4.
At the moment the only way round this for us is disable config watch via spring.cloud.consul.config.watch.enabled
About this issue
- Original URL
- State: closed
- Created 8 years ago
- Comments: 71 (52 by maintainers)
Can you debug your app and put a break point in the
ConsulPropertySourceLocatorconstructor. Capture the stack when that is called (after startup), and attach it here. Or we could do that if you send us a simple sample to reproduce the issue. I don’t see any calls to the constructor once my sample app is up and running.