Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Liveness and readiness probes return down when lazy initialization is enabled #35161

Closed
Storje opened this issue Apr 25, 2023 · 9 comments
Closed
Labels
type: regression A regression from a previous release
Milestone

Comments

@Storje
Copy link

Storje commented Apr 25, 2023

Since Spring Boot 3.0.6, Liveness and Readiness probes return 503 (DOWN)

With this configuration :

spring:
  main:
    lazy-initialization: true
    cloud-platform: KUBERNETES
management:
  security:
    enabled: false
  endpoints:
    web.exposure.include: info,health,prometheus

The following test is red :

@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)
@AutoConfigureObservability
class SupervisionIntegrationTest {

    @Autowired
    lateinit var restTemplate: TestRestTemplate

    @Test
    fun livenessProbe() {
        val response = restTemplate.getForEntity("/actuator/health/liveness", String::class.java)
        assertThat(response.statusCode).isEqualTo(HttpStatus.OK)
    }

    @Test
    fun readinessProbe() {
        val response = restTemplate.getForEntity("/actuator/health/readiness", String::class.java)
        assertThat(response.statusCode).isEqualTo(HttpStatus.OK)
    }

}

The same test with Spring Boot 3.0.5 is ok.
With 3.0.6, if spring.main.cloud-platform is removed, the health probe is ok. When k8s probes are added, the health becomes down.

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Apr 25, 2023
@quaff
Copy link
Contributor

quaff commented Apr 26, 2023

I cannot reproduce it.

@wilkinsona
Copy link
Member

Thanks for trying, @quaff.

@Storje, if you would like us to spend some more time investigating, please spend some time providing a complete yet minimal sample that reproduces the problem. You can share it with us by pushing it to a separate repository on GitHub or by zipping it up and attaching it to this issue. Unless the problem is specific to Kotlin, the sample should ideally be written in Java as it removes one possible source of problems.

@wilkinsona wilkinsona added the status: waiting-for-feedback We need additional information before we can continue label Apr 26, 2023
@marcoranica94
Copy link

marcoranica94 commented Apr 26, 2023

Since Spring Boot 3.0.6, Liveness and Readiness probes return 503 (DOWN)

With this configuration :

spring.main.cloud-platform: KUBERNETES
management:
  security:
    enabled: false
  endpoints:
    web.exposure.include: info,health,prometheus

The following test is red :

@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)
@AutoConfigureObservability
class SupervisionIntegrationTest {

    @Autowired
    lateinit var restTemplate: TestRestTemplate

    @Test
    fun livenessProbe() {
        val response = restTemplate.getForEntity("/actuator/health/liveness", String::class.java)
        assertThat(response.statusCode).isEqualTo(HttpStatus.OK)
    }

    @Test
    fun readinessProbe() {
        val response = restTemplate.getForEntity("/actuator/health/readiness", String::class.java)
        assertThat(response.statusCode).isEqualTo(HttpStatus.OK)
    }

}

The same test with Spring Boot 3.0.5 is ok. With 3.0.6, if spring.main.cloud-platform is removed, the health probe is ok. When k8s probes are added, the health becomes down.

Hi, we have updated spring 3.0.6 and appeared to us same problem.
The problem seems to have temporarily resolved with the addition of this label in application.yml: cloud-platform: none

@spring-projects-issues spring-projects-issues added status: feedback-provided Feedback has been provided and removed status: waiting-for-feedback We need additional information before we can continue labels Apr 26, 2023
@Storje
Copy link
Author

Storje commented Apr 26, 2023

The issue is when lazy init is enabled.
The configuration in first message is updated with the right configuration.

@quaff
Copy link
Contributor

quaff commented Apr 26, 2023

I verified health down with

spring.main:
  lazy-initialization: true
  cloud-platform: kubernetes

@marcorotondi
Copy link

Since Spring-Boot 3.0.6 and Spring-Clound 2022.0.2 The problem occurs randomly.

On the same service released in a docker environment, one service returns DOWN while the other returns UP
by entering

spring.main.cloud-platform=none

The problem no longer occurs.
The only difference from other services is the activation
of lazy-loading:

spring.main. lazy-initialization=true

it seems that lazy-initialization does not lead to the creation of the necessary beans

Problem solved with:
spring.main. lazy-initialization=false and without this:
spring.main.cloud-platform=none

@Storje
Copy link
Author

Storje commented Apr 26, 2023

@wilkinsona here is a sample to reproduce the issue
demo.zip

@wilkinsona
Copy link
Member

Thanks, @Storje. I've yet to figure out why it makes a difference, but the problem can be worked around by preventing the ApplicationAvailability bean from being marked as lazy:

@Bean
fun eagerApplicationAvailabilityBean(): LazyInitializationExcludeFilter {
	return LazyInitializationExcludeFilter.forBeanTypes(ApplicationAvailability::class.java)
}

@wilkinsona wilkinsona changed the title Actuator : Liveness & Readiness probes down Liveness and readiness probes return down when lazy initialization is enabled Apr 26, 2023
@wilkinsona wilkinsona added type: regression A regression from a previous release and removed status: waiting-for-triage An issue we've not yet triaged status: feedback-provided Feedback has been provided labels Apr 26, 2023
@wilkinsona wilkinsona added this to the 3.0.x milestone Apr 26, 2023
@wilkinsona
Copy link
Member

This is a regression caused by the changes for #34347. The return type of the @Bean method has changed from ApplicationAvailabilityBean to ApplicationAvailability. This means that type information is lost and the bean factory cannot tell that it's an ApplicationListener.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: regression A regression from a previous release
Projects
None yet
Development

No branches or pull requests

6 participants