CachingConnectionFactory should allow option to not cache shared consumers [SPR-11958]

[spring-projects-issues]

Christopher Shannon opened SPR-11958 and commented

It might be nice to have a mode/flag on the CachingConnectionFactory to turn off caching of shared consumers (durable or non-durable) if desired.

The original issue doesn't apply (shown below) since the JMS spec allow allows one thread per session concurrently. This means caching won't be a problem unless someone is trying to share a session across threads and shouldn't be. However, there could be use cases to allow more fine grained control in the CachingConnectionFactory so the user can specify what is and isn't cached. Consumers, shared consumes, durables, no durables, etc could potentially be configured separately so that some types are cached and some not cached.

My team will be testing this out extensively and see what kind of use cases we come up with.

-The issue is that the JMS 2.0 spec supports multiple shared consumers on a subscription, unlike JMS 1.1 which only supports one consumer. I can see two use cases:-

-Caching of shared consumers is a good idea if the intention is to stand up multiple JVMs or multiple connections configured with a shared consumer. In this case caching of the consumers should act just like the caching of non shared consumers (which is currently the case) since there should only be one shared consumer for the same destination per connection.-

-However, if the intent is to allow multiple consumers in the same JVM and same connection, then caching of shared consumers would not work as intended. In this use case, it would actually be useful to not cache the shared consumers. The idea here would be to allow multiple threads to have their own shared consumer to make processing multi-threaded. The reason to add this behavior to the CachingConnectionFactory itself is to allow the benefits of caching of other producers/consumers to be re-used with the same factory.-

-I'm not sure if this is something that should be implemented but it is a thought I had. For now, if separate shared consumers are needed a second SingleConnectionFactory can be used that doesn't cache instead.-

---

Affects: 4.0.5

Issue Links:

• CachingConnectionFactory doesn't properly cache all consumers with JMS 2.0 [SPR-11956] #16572 CachingConnectionFactory doesn't properly cache all consumers with JMS 2.0
• Support JMS 2.0's shared consumers in message listener containers [SPR-11969] #16585 Support JMS 2.0's shared consumers in message listener containers

[spring-projects-issues]

Christopher Shannon commented

I went ahead and created a pull request for this issue: #581

Let me know what you think.

Chris

[spring-projects-issues]

Juergen Hoeller commented

Actually, since we're caching producers and consumers per Session instance, wouldn't multi-threaded consumption work in any case? Each thread would have to have its own Session, even if coming from the same JMS Connection, and therefore would end up having its own instances of shared consumers as well - just cached for that specific Session...

Jeurgen

[spring-projects-issues]

Christopher Shannon commented

That's a good point, you are correct since there is one session per thread. I still think that this could be a good improvement because the caching of consumers and shared consumers could be controlled separately with their own flag which might be nice in certain use cases.

Chris

[spring-projects-issues]

Juergen Hoeller commented

It's certainly worth considering in general, I just wonder what the specific use cases would be... where you'd like to cache regular consumers but not shared consumers per JMS Session. Along the same lines, one could wonder whether there are use cases for excluding durable consumers from general consumer caching, as opposed to no-durable consumers.

Juergen

[spring-projects-issues]

Christopher Shannon commented

Yeah, the use cases are more hypothetical and I'm not sure if they would apply for any real problems. My original ticket is certainly a lot less valid with what you pointed out. This weekend I was trying to quickly go through the CachingConnectionFactory and look for any other issues with the new JMS 2.0 functionality before my team trys out the new functionality this week. Obviously the JMS spec forbids having 2 threads share a session concurrently so of course my original point wouldn't happen.

We are going to pull down 4.0.6 as soon as it is released and start testing against that pretty heavily (the snapshots look good so far). With the new bug fixes in place we can start testing out the new JMS 2.0 features and see if we have any use cases that might require more fine grained control of what gets cached.

Chris

[spring-projects-issues]

Juergen Hoeller commented

Sounds good, let me know whether there's anything else you run into, and whether a concrete need for selective caching arises.

4.0.6 will become available tomorrow, then we'll be working towards 4.1 RC1 next week. So we can easily roll further enhancements into the 4.1 release candidate phase...

Juergen

[spring-projects-issues]

Christopher Shannon commented

Will do...I am looking forward to trying out the new JMS annotation configuration in 4.1 as described here : https://spring.io/blog/2014/04/30/spring-4-1-s-upcoming-jms-improvements

Chris