Spring-cloud-netflix: Problem with EurekaHealthCheckHandler configuration in 1.1.2.RELEASE

[tjuchniewicz]

I'm testing Spring Cloud Brixton.SR1 that uses Spring Cloud Netflix 1.1.2.RELEASE. I found that EurekaHealthCheckHandlerConfiguration register EurekaHealthCheckHandler probably to early. In my environmet this code returns empty list:

public class EurekaHealthCheckHandler {
...
@Override
public void afterPropertiesSet() throws Exception {
    final Map<String, HealthIndicator> healthIndicators = applicationContext.getBeansOfType(HealthIndicator.class);

In old version it works fine. Probably configuration is done too early because in 1.1.2 there is no dependency to HealthIndicator class:

@Configuration
@ConditionalOnProperty(value = "eureka.client.healthcheck.enabled", matchIfMissing = false)
@ConditionalOnBean(HealthIndicator.class) // this has been removed in 1.1.2.
protected static class EurekaHealthCheckHandlerConfiguration {
...
}

It is strange but I get this error only when using DiscoveryClient to locate the Config Server.
Second strange behavior is that only when DiscoveryClient is enabled, service is sending health checks (eureka.client.healthcheck.enabled=true) to Eureka but always with status UNKNOWN (as a consequence of problem in EurekaHealthCheckHandler.afterPropertiesSet()).

[tjuchniewicz]

Last changes to EurekaHealthCheckHandlerConfiguration here: #1051

[tjuchniewicz]

@spencergibb Can you take a look on this issue?

[spencergibb]

Have you tried with SR6?

[tjuchniewicz]

The same. I maintain privately my own patch since SR1. I had to apply patch also to spring-cloud-netflix 1.1.6 which is used in SR6.

Maybe I do not understand something but it looks like your commit https://github.com/spring-cloud/spring-cloud-netflix/commit/6b1113e355dd15a24f269dc96618c55d3faaa1cf is broken. Removed @ConditionalOnBean(HealthIndicator.class) from EurekaHealthCheckHandlerConfiguration but in EurekaHealthCheckHandler.afterPropertiesSet() we are searching for: applicationContext.getBeansOfType(HealthIndicator.class);

[spencergibb]

We moved it so that the HealthIndicator instances aren't required at creation time, only later at runtime. Your error make sense since you are using DiscoveryClient in bootstrap which won't have your HealthIndicators yet. We jump through many hoops to get local config server via discovery. Without 6b1113e, health check was severely broken, see #1051.

[cforce]

I t here any reason why @tjuchniewicz fix won't be applied?

[cforce]

@spencergibb
The feature "spring.cloud.config.discovery.enabled=true" in Dalston still does not work.
How to fix workaround this?? There is documentation (http://cloud.spring.io/spring-cloud-static/Dalston.SR3/#discovery-first-bootstrap), but the feature simply does not work and is not fixed ? Why?

This change introduced the Bug!
https://github.com/spring-cloud/spring-cloud-netflix/commit/6b1113e355dd15a24f269dc96618c55d3faaa1cf

[ryanjbaxter]

@cforce this doesnt seem related, perhaps open a separate issue.

[cforce]

It's not just related - its the same source for the problem - see https://github.com/spring-cloud/spring-cloud-netflix/issues/1158#issue-163527338 and the very bottom.

[vasilievip]

@tjuchniewicz do you override "spring.config.location"?
I have the same issue when I put into run args following value:
"classpath:/application.properties,file:/etc/services/services.properties"

[tjuchniewicz]

No. I don't use spring.config.location. My workaround is:

@Configuration
@ConditionalOnProperty(value = {"eureka.client.healthcheck.enabled", "eureka.client.enabled"}, matchIfMissing = false)
@ConditionalOnBean(HealthIndicator.class) // this is actual fix
public class CustomEurekaHealthCheckHandlerConfiguration {

    @Autowired(required = false)
    private HealthAggregator healthAggregator = new OrderedHealthAggregator();

    @Primary
    @Bean
    @ConditionalOnBean(EurekaHealthCheckHandler.class) // to override default bean created by Spring
    public EurekaHealthCheckHandler customEurekaHealthCheckHandler() {
        return new EurekaHealthCheckHandler(this.healthAggregator);
    }
}

[marcingrzejszczak]

Hi @tjuchniewicz , is the problem still there in the latest release train?

[tjuchniewicz]

Hi @marcingrzejszczak I don't know and it's not so easy for me to move to the latest Spring Cloud/Spring Boot to verify :-(

[ryanjbaxter]

@tjuchniewicz is it not possible for you to create a simple project to try and reproduce this using Finchley.SR1?

[tjuchniewicz]

@ryanjbaxter This is not so easy. We built set of parent poms on the top of Spring Cloud. Update is always painful. I will try to check this next week.

[tjuchniewicz]

Sorry guys. I can't verify quickly. It will take weeks to update from Dalston to Finchley. To many changes in Spring Boot and Spring Cloud frameworks... I'm not able to extract simple test case quickly :-(

[spencergibb]

Please post something here if you can in the future and we can reopen