Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CachedMessageProducer does not support all JMS 2.0 MessageProducer methods [SPR-11950] #16567

Closed
spring-projects-issues opened this issue Jul 3, 2014 · 6 comments
Assignees
Labels
type: bug
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

@spring-projects-issues spring-projects-issues commented Jul 3, 2014

Christopher Shannon opened SPR-11950 and commented

#16566 fixes CachedMessageProducer so that Jms2MessageProducerInvocationHandler properly delegates calls to CachedMessageProducer.this.

However, only 2 out of the 4 new methods are supported that exist in the JMS 2.0 MessageProducer interface.

The following 2 methods are not supported by the proxy:

send(Message message, int deliveryMode, int priority, long timeToLive, CompletionListener completionListener)

send(Destination destination, Message message, int deliveryMode, int priority, long timeToLive, CompletionListener completionListener)

For example, when attempting to execute one of these methods the following error occurs:

java.lang.AbstractMethodError: org.springframework.jms.connection.CachedMessageProducer.send(Ljavax/jms/Destination;Ljavax/jms/Message;IIJLjavax/jms/CompletionListener;)V
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.springframework.jms.connection.CachedMessageProducer$Jms2MessageProducerInvocationHandler.invoke(CachedMessageProducer.java:287)
.......


Affects: 4.0.5

Issue Links:

  • #16566 CachingConnectionFactory doesn't properly cache producers with JMS 2.0
@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jul 4, 2014

Stéphane Nicoll commented

The root of the problem is that we can't easily test JMS 2.0 specific methods. I'll research what we can do to avoid that kind of inconsistency in the future.

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jul 4, 2014

Stéphane Nicoll commented

Thanks for the report. This is now fixed in master.

Juergen Hoeller, I guess this should go in your backport list.

I have added some integration tests before fixing those methods and made sure they were failing as you mentioned. Unfortunately, we can't use both the JMS 1.1 and 2.0 APIs in the same project. I have started to craft an integration test infrastructure for the framework, you can find that in 1a66915

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jul 4, 2014

Juergen Hoeller commented

This is a kind of side effect of #16566: When delegating to the broker's actual Provider implementation (which is JMS 2.0 compliant in such a case), we don't need to specifically handle all CompletionListener call variants - we just need to intercept the ones with custom configuration settings. However, with #16566's resolution, we are delegating to Spring's own CachedMessageProducer which doesn't implement any JMS 2.0 CompletionListener methods, so indeed, now we need to specifically handle all of Producer's JMS 2.0 methods there.

I'm backporting this to 4.0.6 now, just like #16566.

Juergen

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jul 4, 2014

Juergen Hoeller commented

This will be available in the upcoming 4.0.6.BUILD-SNAPSHOT. Feel free to give it a try, Christopher...

Juergen

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jul 4, 2014

Christopher Shannon commented

Thanks for the quick response guys...I was going to submit a pull request for this issue this morning but I woke up and it was already fixed. The integration test is essentially what I did last night. I just added the jms 2.0 api and used mockito to mock out everything to prove that those methods would in fact fail. Unfortunately, #16566 wouldn't fail with a mock...a real broker would probably be needed to catch this kind of bug.

I did some research and it looks like Glassfish MQ 5 does support JMS 2.0 if you were looking for a real broker to test against. Besides Tibco EMS, our team also uses ActiveMQ but that broker does not support JMS 2.0 yet.

Since our team uses Spring's JMS support heavily (JmsTemplate, DefaultMessageListenerContainer, etc),I will go back and try everything out with our Tibco broker and create new issues if I come across any problems.

Chris

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jul 4, 2014

Stéphane Nicoll commented

that's awesome Chris, thanks a lot! You can also use HornetQ if you want to test against a JMS 2.0 broker.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: bug
Projects
None yet
Development

No branches or pull requests

2 participants