The default JMS DestinationResolver implementation used by Spring Framework, DynamicDestinationResolver, doesn't implement CachingDestinationResolver and therefore doesn't cache the resolved destinations. This can have significant performance implications in cases where JMS provider does some expensive work in their jakarta.jms.Session#createQueue/#createTopic implementations and/or with high-volume workloads.
Since resolved destinations should typically be stable, and Framework in some places already refreshes destination cache on critical failures if working with CachingDestinationResolver, it seems safe to have a default JMS DestinationResolver implementation that caches the results.
At the very least, Spring Framework could provide CachingDestinationResolver implementation that wraps other DestinationResolver implementation and caches the results (analogous to the org.springframework.messaging.core.CachingDestinationResolverProxy), and (hopefully) use that as the new default implementation.
If you would consider such contribution, I can provide a PR along these lines shortly.
Comment From: jhoeller
Thanks for raising that concern, Vedran! Indeed, with modern JMS brokers, it seems that Session.createQueue|Topic returned instances are commonly stable and reusable. We can take a chance there for 7.0 and cache them by default.
So I went ahead and introduced a SimpleDestinationResolver as our new default for common JMS setups. This is a subclass of DynamicDestinationResolver with some extra assumptions made so that it can internally cache Queue and Topic instances (separately for defensiveness against namespace overlaps that are not explicitly forbidden). The "Simple" name matches other defaults in JMS and that term also implies that the destinations themselves needs to be "simple": not Session-specific and therefore stable across an entire JMS setup. Making this our new default also goes along nicely with the introduction of JmsClient.
Comment From: vpavic
Thanks for addressing this in time for 7.0, much appreciated. Your solution is very similar to what I had in place in a few projects, so I'm looking forward to being able to shed that code.