@wilkinsona The BPPs are exposing those
@Endpoints. When I expose it in the properties file in tests, it works fine as those properties are resolved and evaluated before AutoConfiguration decides with @ConditionalOnAvailableEndpoint, however, I want to avoid forcing everyone to manually put some configs, and rather I expose it programmatically
Since prometheus is not exposed by default. I want to programmatically expose it at the start up in our shared library
To prevent asking every micro-service to expose in their
application.yml
My BPP is exposing prometheus metrics on
/metrics endpoint. Bydefault, it's /actuator/prometheus
@wilkinsona Is the problem clear now?
@wilkinsona here's the discussion in github about how it's evolved spring-projects/spring-boot#16169 @bclozel @snicoll
Good morning all,
I built an API which sends sms or three instances is deployed, at the beginning it was running on tomcat for a moment we start by receiving the error
I built an API which sends sms or three instances is deployed, at the beginning it was running on tomcat for a moment we start by receiving the error
Too many open files I tried several solutions until migrating spring boot 2.2.2 then jetty but after a while I still receive org.eclipse.jetty.server.HttpChannel - handleException /api/sender java.io.IOException: Too many open filesWhat can be the problem ? Thank you
Probably because you're leaking them somewhere, but perhaps you've just tuned your deployment wrong for your traffic.
(or not tuned it)
@wilkinsona beautiful!! Is that
EnvironmentPostProcessor gets evaluated before those @Conditional...s are evaluated? 2. If I add it there, then if clients want to say exclude it in their application.yml, then what's the behaviour? what takes the precedence? My guess is that it can be handled in the EnvironmentPostProcessor :)
Can some guide me with a reference how to implement distributed tracing with spring slueth & zipkin with latest springboot version?
Gg
@wilkinsona There's one nuance with
management.endpoints.web.exposure.include is that it takes a comma-separated list. So in this case, if you add a new property source for each endpoint (in my case they are in different modules and each has its own EnvPostProcessor), then the one which is first in the order, is the one that's exposed, and the rest is not exposed. In this case, is it fair to solution to scan through environment.propertySources and find the first instance where management.endpoints.web.exposure.include is defined and alter (append new endpoint) it there? Or is there a better way?
@vegeta03 your question is so broad, that it is impossible for anyone here to understand exactly what you want us to help you with. Have you built an application that you want to deploy, if so, with what kind of setup/infrastructure? Or, do you want to learn how to build an application with the named technologies?
My issue is about springboot test does not import MessageSourceAutoConfiguration.
@ImportAutoConfiguration(classes = {
MessageSourceAutoConfiguration.class
})
public class I18nConfig {
/* some beans */
}
@RunWith(SpringRunner.class)
@ContextConfiguration(classes = I18nTest.TestConfig.class)
@ActiveProfiles("test")
public class I18nTest {
/* tests are here */
@TestConfiguration
@Import({
I18nConfig.class
})
public static class TestConfig {
}
}
and my test says me that MessageSource is instance of DelegatingMessageSource, messageSource=Empty MessageSource - but MessageSourceAutoConfiguration instantiates ResourceBundleMessageSource bean
why MessageSourceAutoConfiguration does not work this way?
I want to run the same junit5 tests class 3 times, each time with a context property set to a different value. Is there a nice way to do that?
@ParameterizedTest is only method not class level, and whilst I could use @DirtiesContext(AFTER_EACH_TEST_METHOD)to recreate the context that is quite expensive to do per test and I can't see how to set the context property before the context is initialized.
I see - thank you for clarifying. Have you read https://docs.spring.io/spring/docs/current/spring-framework-reference/web-reactive.html#webflux-server-choice?
Question for the community but we are running into very slow spring boot startup times when deploying a spring boot docker image through kubernetes (up to 120 seconds). I have looked at the Spring Boot Benchmark that Dave Syer has provided (https://github.com/dsyer/spring-boot-startup-bench) but in my environment, the CPU settings used are still significantly faster than what have/use. Does anyone have any documentation/best practices or anything on improving Spring Boot startup times? We are also starting to evaluate GraalVM to see if we can get some performance improvements as well but wanting to get some feedback from the Spring Boot team if possible.
@bclozel I can grab some of our tests, but specifically the issue is based on the CPU allocated to the startup of the application. There was a specific amount we could allocate that would allow the application to boot in 1-2 seconds. But once we hit that threshold, it would increase significantly (up to 120 seconds). The application we were testing with specifically was a basic Spring Boot application through start.spring.io with just Spring Web. We ran a docker image of it with a setting similar to this: docker run --cpus=".4" spring_min:latest and it showed similar startup times locally. I'll post more information about our tests when I can get the latest copy of it.
@bclozel I have checked in a benchmark application to directly show the performance we are seeing here: https://github.com/miller79/spring-boot-benchmark I have ran on my box with .4 CPU and seeing 30 seconds plus start up time. This is as bare of an application I could create but would like some feedback on if there are any other enhancements we can do to increase performance. My current CPU is an i7-7600U @ 2.8GHz with 16 GB of ram.