Gauges for the number of MessageChannels, MessageHandlers, and MessageSources may cause a BeanCreationNotAllowedException when the context is closed

[wilkinsona]

In what version(s) of Spring Integration are you seeing this issue?

This was reported against Spring Integration 5.2.6, but I believe older and newer versions are also affected.

Describe the bug

Spring Integration registers 3 gauges where the value is calculated by calling getBeansOfType() on the application context for MessageChannel, MessageHandler, and MessageSource beans. It does so in such a way that there are no bean dependency relationships between the meter registry and the MessageChannel, MessageHandler, and MessageSource beans. During context close processing, this allows those beans to be destroyed before the meter registry is destroyed. As a result query the gauges in the meter registry can result in bean creation being attempted and a BeanCreationNotAllowedException is then thrown.

To Reproduce

Courtesy of @tkvangorder, a sample that reproduces the problem is available here. There's also some background information in this Spring Boot pull request.

Expected behavior

Gauges should be implemented or registered in such a way that the MeterRegistry can be used during application context close processing.

Sample

https://github.com/tkvangorder/spring-task-issue

[artembilan]

Hi @wilkinsona !

Thank you for the report. I probably recall something similar on StackOverflow and that was suspicious to call some metrics during application context close... Since it is raised again and against Spring Boot, let's really see what we can do.

I'm not fully sure what you mean with the "should be implemented or registered in such a way that the MeterRegistry". Can you, please, elaborate what is an idea?

I probably can take a look into destroy() method to remove those gauges, but looks like you suggest something different...

Thanks

[wilkinsona]

should be implemented or registered in such a way that the MeterRegistry

I had a couple of ideas in mind. In terms of implementation, the getBeanOfType call could be protected with a try-catch block or a check on the context's state. However, that feels more like a workaround then a solution. In terms of the bean registration, things could be configured such that the MeterRegistry has a dependsOn relationship with the message channel, message source, and message handler beans. This would mean that Framework then destroyed the beans in the right order.

[artembilan]

Thanks, but yeah... Probably that's not so easy to do. More over I think such an info is not so reasonable when we close an application context. So, I more believe that removal of those gauges from the destroy() impl is the right way to go.
In fact we remove meters in many other places, but have missed these gauges somehow...

[artembilan]

So, I prepared the fix with my best judging how to deal with the problem: #3377.

Thanks