Introduce dedicated interface to listen for ClassPathChangedEvents. #17291
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
So far, LocalDevToolsAutoConfiguration had registered a Lambda-based event listener for ClassPathChangedEvents. As the generics information is not available for lookup from a Lambda defined generic interface, SimpleApplicationEventMulticaster.doInvokeListener(…) has no chance but to submit *all* events published to the listener, catching the ClassCastExceptions resulting from that to log them into the TRACE level. For applications that produce a lot of events (esp. during startup) like ones that use Spring Data MongoDB which uses the events to trigger index creation etc., this means that a lot of exceptions are thrown and ultimately discarded most of the time. This commit introduces a dedicated interface for that particular application listener so that it can be discarded for all events but the one it's really interested in, thus avoiding the superfluous exceptions being produced and ultimately leading to better (startup) performance. This was tested using Spring Data Examples (rest/starbucks) and lead to a startup time improvement of ~500ms. The example uses Spring Data MongoDB whose object mapping is heavily making use of application events when reading and writing objects to the database. I assume the effect will be less visible in applications using application events less intensively.
spring-projects-issues
added
the
status: waiting-for-triage
|
It's a shame we need to do this because the generics are available in the bytecode, it's just that they're on the factory method and not the bean instance. |
|
I've raise spring-projects/spring-framework#23178 to see if there's not a more general solution that Framework can apply. If they can't we'll do the change in Boot. |
philwebb
added
type: enhancement
snicoll
added
the
status: blocked
|
Looks like Framework has taken care of this for us. |
wilkinsona
added
status: superseded
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
So far,
LocalDevToolsAutoConfigurationhad registered a Lambda-based event listener forClassPathChangedEvents. As the generics information is not available for lookup from a Lambda defined generic interface,SimpleApplicationEventMulticaster.doInvokeListener(…)has no chance but to submit all events published to the listener, catching theClassCastExceptionsresulting from that to log them into theTRACElevel.For applications that produce a lot of events (esp. during startup) like ones that use Spring Data MongoDB which uses the events to trigger index creation etc., this means that a lot of exceptions are thrown and ultimately discarded most of the time.
This commit introduces a dedicated interface for that particular application listener so that it can be discarded for all events but the one it's really interested in, thus avoiding the superfluous exceptions being produced and ultimately leading to better (startup) performance.
This was tested using Spring Data Examples (rest/starbucks) and lead to a startup time improvement of ~500ms. The example uses Spring Data MongoDB whose object mapping is heavily making use of application events when reading and writing objects to the database. I assume the effect will be less visible in applications using application events less intensively.