-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Description
In what version(s) of Spring Integration are you seeing this issue?
I can reproduce the "issue" for Spring Integration version 5.2.8.RELEASE but I can see in version 5.4.0.RELEASE (https://github.com/spring-projects/spring-integration/blob/v5.4.0/spring-integration-core/src/main/java/org/springframework/integration/config/IntegrationManagementConfigurer.java) that the gauge definitions are equals. The conflictive code is at "registerComponentGauges" method.
private void registerComponentGauges() {
this.gauges.add(
this.metricsCaptor.gaugeBuilder("spring.integration.channels", this,
(c) -> this.applicationContext.getBeansOfType(MessageChannel.class).size())
.description("The number of message channels")
.build());
this.gauges.add(
this.metricsCaptor.gaugeBuilder("spring.integration.handlers", this,
(c) -> this.applicationContext.getBeansOfType(MessageHandler.class).size())
.description("The number of message handlers")
.build());
this.gauges.add(
this.metricsCaptor.gaugeBuilder("spring.integration.sources", this,
(c) -> this.applicationContext.getBeansOfType(MessageSource.class).size())
.description("The number of message sources")
.build());
}
Describe the bug
The bug will be reproducible when any application based on SpringBoot with Micrometer starts to close Spring Application context when the app receive the graceful shutdown signal. In that moment, the micrometer registry try to send the gauge metrics related to "spring.integration.channels", "spring.integration.handlers" and "spring.integration.sources".
The lambda that is executed to collect the values for that metrics invoke to Spring context (this.applicationContext.getBeansOfType(MessageHandler.class).size()
) producing that the context try to create the beans of the types MessageHandler
, MessageChannel
or MessageSource
. This try to create the beans fails and throw a message
Singleton bean creation not allowed while singletons of this factory are in destruction
because, obviously, the context is in destruction phase.
To Reproduce
To reproduce this bug is enough to create an application with micrometer (and a meter registry as a @bean) and wait that the context start to destruction phase.
Expected behavior
In my opinion, the lambda functions to retrieve the metrics should be designed in other way, avoiding to check the spring context each time that we want to retrieve the metric value.
Another suggestion that maybe should be in another different issue is the way to disable the metrics. As I know, we don't have any way/property to disable the registration (and future shipping) of the metrics related to spring integration.
I found a workaround that is using an SpringBoot Actuator property, but that property is not efficient because affect as a meter filter, but In my opinion, we should act at the origin, without interacting with micrometer.
Sample
I don't have any standard project now to publish. I have my own code that belongs to my company and I can't publish right now. I think that is easily reproducible.