Two new methods in the new JMS 2.0 Session interface are not handled properly by CachedSessionInvocationHandler in CachingConnectionFactory. The method signatures are:
When calling createSharedConsumer (either method), the CachedSessionInvocationHandler invoke method never delegates to getCachedConsumer like it should and instead delegates to the target. This means that when calling createSharedConsumer, a new consumer will be created each time and will never be cached into the consumers map as they should.
The fix should be straightforward....there just needs to be an else if statement to handle createSharedConsumer method calls and then delegate to getCachedConsumer()
We covered JMS 2.0's createSharedDurableConsumer but apparently forgot to include the regular createSharedConsumer as well. Fixing this for 4.1 RC1 and 4.0.6 now, along with the previous JMS 2.0 related changes. Thanks for pointing all of those out - much appreciated!
Good catch Juergen. I was going over the JMS 2.0 spec in more detail and testing things out and thought of a new feature that might be useful so I created #16574. I'm not sure if this feature is something that belongs in the CachingConnectionFactory or not but thought I would create the issue anyways. Feel free to close it out if it's something that you think isn't necessary.
Christopher Shannon opened SPR-11956 and commented
Two new methods in the new JMS 2.0 Session interface are not handled properly by CachedSessionInvocationHandler in CachingConnectionFactory. The method signatures are:
MessageConsumer createSharedConsumer(Topic topic, String sharedSubscriptionName) throws JMSException;
MessageConsumer createSharedConsumer(Topic topic, String sharedSubscriptionName, java.lang.String messageSelector)
throws JMSException;
When calling createSharedConsumer (either method), the CachedSessionInvocationHandler invoke method never delegates to getCachedConsumer like it should and instead delegates to the target. This means that when calling createSharedConsumer, a new consumer will be created each time and will never be cached into the consumers map as they should.
The fix should be straightforward....there just needs to be an else if statement to handle createSharedConsumer method calls and then delegate to getCachedConsumer()
This is related to #16566
Affects: 4.0.5
Issue Links:
The text was updated successfully, but these errors were encountered: