JMSTemplate should support setting QoS settings on send [SPR-5183]

[spring-projects-issues]

Christian Schneider opened SPR-5183 and commented

JMSTemplate currently supports QoS settings like: deliveryMode, priority, timeToLive

While this is ok if you want to set these only once it makes some problems if you want to set them new for each message. If you set the properties before doing the send the code is not threadsafe anymore.
See http://fisheye6.atlassian.com/browse/cxf/trunk/rt/transports/jms/src/main/java/org/apache/cxf/transport/jms/JMSDestination.java?r=700236#l251

I have currently ignored the threading problem but I have to correct this before the new CXF version is released. So what I would like to have is a send method that allows setting the QoS stuff like in producer. Alternatively I would be happy if there is some easy workaround.

This is the code that decides about QoS

protected void doSend(MessageProducer producer, Message message) throws JMSException {
if (isExplicitQosEnabled()) {
producer.send(message, getDeliveryMode(), getPriority(), getTimeToLive());
}
else {
producer.send(message);
}
}

---

Affects: 2.5.5

[spring-projects-issues]

Juergen Hoeller commented

In a scenario like this, you need to reinstantiate a JmsTemplate for each such message: setting the ConnectionFactory, setting the QoS settings, then calling "send". Creating JmsTemplate instances is quick and efficient, just like for other Spring template classes...

Juergen

[spring-projects-issues]

Christian Schneider commented

For my current case the scenario you suggest will work as I am creating the JmsTemplate in my class out of a config class.
But what if my code gets a JmsTemplate injected? I use something like the following code to decide what kind of JmsTemplate to use:
JmsTemplate jmsTemplate = useJms11? new JmsTemplate() : new JmsTemplate102();
If I get the template by injection then I should not decide myself which class to instantiate.

This leads me to another question I have: What is the prefered way to do the configuration? Should I rather get the template injected or create it in my class?

I think the spring way would be to rather get the template injected. So the user of my code can decide which template to use and even could subclass JmsTemplate himself. Some time before I had my code this way. The JmsConfiguration class simply had a property JmsTemplate instead of the detailed configurations. At some point I changed this because the Template and the listener had some common configuration settings that I could define once in my current approach and had to define twice before. But I am still not sure my decision was so good. for example I do not currently offer all settings of the DefaultMessageListenerContainer so I constrict the user quite a bit. Even by deciding to use the DefaultMessageListenerContainer I take away his freedom to choose another implementation.

[spring-projects-issues]

Christian Schneider commented

I have changed my code to create the JmsTemplate each time.
http://fisheye6.atlassian.com/browse/cxf/trunk/rt/transports/jms/src/main/java/org/apache/cxf/transport/jms/JMSConduit.java?r1=700308&r2=701354#seg13

This should do the trick for now. Any ideas what to do in the case I described above?

[spring-projects-issues]

Antony Bowesman commented

I have the same problem. I am gatewaying events from another non JMS (non Java) system. Those events can specify TTL, priority and delivery mode. As a result I have had to use a pool of JmsTemplates using CommonsPoolTargetSource, but this seems like complete overkill just to get the concurrency on what is all other respects I understand is a a thread safe class.

Looking at the existing code, there doesn't appear to be a clean way to add a callback to get these for the MessageProducer, but could each of the existing 3 send() methods be overloaded to provide these attributes?

[spring-projects-issues]

Ross Duncan commented

I have this problem too. For me the workaround of creating a new JmsTemplate every time is no real burden as I am writing a new application. However, I would have thought the QoS variables would have been settable either as part of the jmsTemplete.send method, or through some exposure to the MessageProducer.

I hope this does get addressed at some point.

[spring-projects-issues]

Dave Syer commented

ProducerCallback exposes the MessageProducer directly. What's wrong with using that?

[spring-projects-issues]

Amin Abbaspour commented

http://aminsblog.wordpress.com/2010/04/27/publishing-qos-priority-enabled-messages-using-spring-jms-template-2/

[spring-projects-issues]

Rossen Stoyanchev commented

This issue has been resolved through a selective bulk update, as part of a larger effort to better manage unresolved issues. To qualify for the update, the issue was either created before Spring 3.0 or affects a version older than Spring 3.0 and is not a bug.

There is a good chance the request was made obsolete, or at least partly outdated, by changes in later versions of Spring including deprecations. It is also possible it didn't get enough traction or we didn't have enough time to address it. One way or another, we didn't get to it.

If you believe the issue, or some aspects of it, are still relevant and worth pursuing at present you may re-open this issue or create a new one with a more up-to-date description.

We thank you for your contributions and encourage you to become familiar with the current process of managing Spring Framework JIRA issues that has been in use for over a year.

[alwibrm]

Unfortunately this issue has been closed though it would be a nice feature.