/health URL says server is down

[ewolff]

I ran the Eureka server using mvn spring-boot:run

curl localhost:8761/health says {"status":"DOWN"}

Log output of the Eureka server:

2015-03-12 09:36:02.729 ERROR 47272 --- [nio-8761-exec-3] c.c.c.ConfigServicePropertySourceLocator : Could not locate PropertySource: I/O error on GET request for "http://localhost:8888/application/default/master":Connection refused; nested exception is java.net.ConnectException: Connection refused

[ewolff]

I get the same log output when the application starts:

mvn spring-boot:run [INFO] Scanning for projects... [INFO]
[INFO] ------------------------------------------------------------------------ [INFO] Building Eureka Server 0.0.1-SNAPSHOT [INFO] ------------------------------------------------------------------------ [INFO] .... 2015-03-12 09:32:56.295 INFO 47272 --- [lication.main()] eurekademo.EurekaApplication : Starting EurekaApplication on UltraLight.localdomain with PID 47272 (/Users/wolff/Documents/workspaces/SpringCloud/eureka-1.0.0.RELEASE/target/classes started by wolff in /Users/wolff/Documents/workspaces/SpringCloud/eureka-1.0.0.RELEASE) 2015-03-12 09:32:56.441 INFO 47272 --- [lication.main()] s.c.a.AnnotationConfigApplicationContext : Refreshing org.springframework.context.annotation.AnnotationConfigApplicationContext@43f419aa: startup date [Thu Mar 12 09:32:56 CET 2015]; root of context hierarchy 2015-03-12 09:32:56.732 INFO 47272 --- [lication.main()] f.a.AutowiredAnnotationBeanPostProcessor : JSR-330 'javax.inject.Inject' annotation found and supported for autowiring 2015-03-12 09:32:57.174 INFO 47272 --- [lication.main()] eurekademo.EurekaApplication : Started EurekaApplication in 1.509 seconds (JVM running for 6.827)

. _ /\ / **' () \ \ \ \ ( ( )** | ' | '| | ' \/ ` | \ \ \ \ \/ _)| |)| | | | | || (| | ) ) ) ) ' |_| .**|| ||| |**, | / / / / =========||==============|_/=///_/ :: Spring Boot :: (v1.2.2.RELEASE)

2015-03-12 09:32:57.845 ERROR 47272 --- [lication.main()] c.c.c.ConfigServicePropertySourceLocator : Could not locate PropertySource: I/O error on GET request for "http://localhost:8888/eureka/default/master":Connection refused; nested exception is java.net.ConnectException: Connection refused

[spencergibb]

It's trying to connect to config server.

[ewolff]

Yes - but is this expected behavior? The Readme says nothing about a required config server.

[spencergibb]

yes, it is, we should change the readme.

[ewolff]

OK. I'd prefer if this was really the minimal setup for an Eureka server. There are other issues e.g. unused Spring configuration profiles and also I could not get the server working with authentication. Do I'd rather strip it down. That would also make it much easier to the sample.

Thanks for looking into this!

[dsyer]

There's a completely minimal Eureka Server here if you need something with less noise: https://github.com/spring-cloud-samples/tests/blob/master/turbine/src/test/java/apps/EurekaServerApplication.java. Generally the "spring-cloud-samples/tests" are the "minimal, do no more than you need to" samples. Even that is a challenge though (hence the presence of a Eureka Server in a Turbine sample). The top-level samples in spring-cloud-samples are generally not minimal - they form a system that is supposed to be a little bit "realistic" (it gets used a lot for demos). Maybe we should invert the roles played by spring-cloud-samples/tests and spring-cloud-samples/*, or maybe we should put the "realistic" samples somewhere else. What do you think?

The health indicator thing is probably worth a discussion on the Spring Cloud Config issue tracker - it's a difficult balance to strike between things that work out of the box in isolation, and things that form a distributed system. I don't see any documentation in the user guide yet for the config server health indicator, but it definitely is needed (please raise an issue). Anyway, the server doesn't fail to start (by default), it just shows as DOWN in the /health endpoint. And you can run a Eureka Server with no Spring Config dependencies, in which case it will not care that the config server is not running. But we chose to put spring-cloud-config-client in all the spring-cloud-starter-*. If you think that needs to be discussed further, please open an issue in the starters project.

[ewolff]

Thanks for the link!

I would prefer the samples here to be minimal. Quite honestly I'd rather look at the a sample called Eureka than at a test for Turbine. If you decide to keep the more complex sample here the documentation needs to be improved. At least I am not sure what all the features of this sample are.

Concerning the /health resource: http://docs.spring.io/spring-boot/docs/current-SNAPSHOT/reference/htmlsingle/#production-ready-health states that the /health resource should report whether the system is available or not. I'd argue that {"status":"DOWN"} is not the correct answer if the server is in fact available. Note that this is not the health of the config server but of the Eureka server.

I will open an issue concerning the Sping Cloud Config dependency.

Thanks!

[dsyer]

Thanks for all the feedback. I'll think about stripping down the top level samples to be more self-contained, but I'm not really convinced it's the right thing to do yet.

Maybe we can move the /health discussion to the Spring Cloud Config project as well?

[ewolff]

I think the problem concerning the health resource belongs here. The sample as it is reports that it is down even if it is fully functional. That appears to be a bug IMHO...

[dsyer]

If you agree that this is the correct default behaviour for a config client, then we should discuss it here. I think there may be some useful changes we could make, but I prefer not to discuss that here.

The scope of this issue then should be just that you believe that the health indicator and/or the config client should be switched off for this sample. I'm not sure I agree, since (as it stands anyway) this sample is part of a bigger system that does require the config server.

If we decide to simplify this sample so it is a standalone eureka server with no assumptions that situation would change. I'm really not sure that's the right decision yet though (we want to be realistic and make the system as it would be in a non-sample environment).

[dsyer]

Fixed in 1.0.1 (see https://github.com/spring-cloud/spring-cloud-config/issues/104)