When reading through the spring boot documentation (http://docs.spring.io/spring-boot/docs/1.2.1.RELEASE/reference/htmlsingle/#production-ready-customizing-management-server-port), I see that you can customize the port on which actuator is running. If I am using embedded tomcat, how is this implemented? Is this creating another Connector or is it starting up a different instance of tomcat all together? If it is tomcat, do we have any idea how much more memory this takes?
-Joshua
It starts a separate embedded instance of Tomcat. The /metrics endpoint of Spring Boot's Actuator or a tool like JConsole will give you some insight into the heap usage.
Related
Was wondering the recommended way of starting a spring boot app if the Spring cloud config server is temporarily down or unavailable. What would be the approach? I know of the retry configurations, but I am wondering if there is a way to have a 'replica' config server and use that as a failover (or something along those lines).
Sure, why not?
After all, spring-cloud-config server exposes rest API and all the interaction with spring boot microservices is done over HTTP.
From this point of view, you can scale out the spring cloud config server by providing more than one instance of it all are up-and-running and mapping them to one virtual IP.
If you're running in some kind of orchestrated environment (like kubernetes) it is a very easy thing to do.
Is Spring cloud config server an example of sidecar application for microservices?
Do you mean if the Spring Cloud Config Server itself is what the Spring Cloud documentation labels as Sidecar? Then no, as far as I know it is just a plain, regular Spring Boot app.
A Sidecar as referred to in Polyglot support with Sidecar is a Spring Boot application that acts as a bridge between your service infrastructure and a service that is not written in a JVM language. Apps written in Python, Go, Ruby, C#, NodeJS, Erlang or really any other language that can bind something to a port come to mind.
The benefits of the Sidecar are, that your Non-JVM apps
service discovery become automatically discoverable through Eureka, which means that JVM services can resolve the host:port/<service-id> of the Non-JVM apps as well as the other way around,
monitoring are monitorable through the same health-endpoints-infrastructure that is available in Spring Boot (Actuator), i.e. by manually providing the health endpoint in the Non-JVM app Eureka knows when the Non-JVM service is down
routing/proxying query the services by either manually looking up their hosts/ports or proxying these requests through Zuul, which in turn resolves their current addresses through Eureka
balancing be load balanced by Ribbon and
configuration may consume configuration properties provided via Spring Cloud Config.
I hope this answer addresses your question, if not (or someone finds it to be inaccurate or misleading) just let me know and I delete it to make room for something more suitable. ;-)
Background:
We have a set of about 15 Spring Boot applications as microservices. They all run as Docker containers, and run as clusters of one or more instances. We also use Spring Cloud Netflix components such as Eureka and discover the running application instances from the client using Feign/Ribbon.
Question:
As part of the POC exercises, we tested with Redis and Hazelcast for caching and Spring Boot configuration storage. Everything works using Spring Boot, Spring Cloud and Redis/Hazelcast Java client libraries. However, when we deploy Hazelcast in a multi-node peer-to-peer cluster, Hazelcast seems to require a "known" IP address/hostname and the accessible port to be available in the Java client's configuration (with or without Spring). Typically, when Hazelcast is deployed in a multi-instance cluster on ephemeral VM instances (for example, EC2), the IP address and the port information is not available. So we thought of two possible solutions:
Find a way to run Hazelcast as a Spring Boot application, and register it with Eureka as a Discovery Client. That way other Spring Boot applications can use Eureka to discover an instance of Hazelcast dynamically
Find a way in Hazelcast so that it can publish it's IP address and port information dynamically to a central Key/Value store
If anyone has played around with Hazelcast to be able to do either/both of the possible solutions, it would be great if you can share more information on that. If there is a third approach that'd work better, I will be eager to know that as well.
Based on an answer from #andy-wilkinson to a past Spring Boot question, it appears that with the exception of a couple parameters (port for example), the management server leverages the same configuration as the regular servlet container.
I would like to configure the main Spring Boot server to use HTTPS (for the application/service it is serving) and to use just HTTP for the actuator endpoints. Has anyone done this? Is this even possible?
-Joshua
It's not possible at the moment. Please open an issue if it's an enhancement that you'd like to see.
Is there a simple way to use (or reuse) external Jetty configuration files to configure an embedded Jetty web container with Spring Boot.
Programmatic configuration to change only the listening port for example is acceptable, but a full configuration including multiple connectors, thread pools, etc. seems to be better suited with usual Jetty files.
Thanks for your help.
Regards.
There's no support in Spring Boot for configuring Jetty via XML. You can use application.properties for simpler cases or programmatic configuration for things that are more complex.
Boot's Tomcat integration is a little bit ahead of its Jetty integration in terms of what you can configure via application.properties. For example, you can configure Tomcat's thread pool. If you'd like to see some improvements to the Jetty integration then please open an issue, or, even better, a pull request.