Re: Non-persistent deliverymode not effect.

[Phil White <pw...@gmail.com>]

Two years on I saw the same thing, that Spring's JMSTemplate seems to ignore
non-persistent delivery configuration, and always sends as persistent.
Tracing through JMSTemplate it turns out that deliveryMode, priority, and
timeToLive are ignored during send() unless "explicit QOS" is enabled, ie.
jmsTemplate.setExplicitQosEnabled(true). Or alternatively the equivalent in
the Spring app context:

	<bean id="jmsTemplate" class="org.springframework.jms.core.JmsTemplate">
		<property name="connectionFactory">
			<ref local="jmsFactory"/>
		</property>
		<property name="pubSubDomain" value="true"/>
		<property name="deliveryPersistent" value="false"/>
		<property name="deliveryMode" value="1"/>
		<property name="explicitQosEnabled" value="true"/>
	</bean>

I'm sure the OP found the same thing out years ago, but just for anyone else
with the same problem.



--
View this message in context: http://activemq.2283324.n4.nabble.com/Non-persistent-deliverymode-not-effect-tp4680457p4714981.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: Non-persistent deliverymode not effect.

[Phil White <pw...@gmail.com>]

It's a fair point, and I've used both approaches in the past, but when you're
using the Spring framework for almost everything else then it's natural to
also use its messaging abstractions, and in most cases it does simplify JMS
usage and configuration. While looking into the persistence problem I found
numerous posting about JMSTemplate's performance failings, but as detailed
in chriswongdevblog.blogspot.co.uk/2013/01/jmstemplate-is-not-evil.html the
problem often turns out to be because Spring applies defaults which aren't
optimal in many applications, and in practice it's a fairly thin shim over
the JMS API.
I suppose there are similar arguments for and against most API abstractions,
for example Spring data vs  Hibernate (or other ORM) vs JDBC vs ODBC vs
specific database APIs. If performance or fine grained control is key then
diving in at a lower level makes sense, but often the higher level
abstraction provides convenience at a small expense.



--
View this message in context: http://activemq.2283324.n4.nabble.com/Non-persistent-deliverymode-not-effect-tp4680457p4715000.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: Non-persistent deliverymode not effect.

[Clebert Suconic <cl...@gmail.com>]

I don't remember who was it.. but I spoke with some Spring guy some
time ago, and even him didn't like SpringTemplate. ;)


Why not simply use simple JMS API? and I'm speaking from the POV of
any JMS server. not just ActiveMQ.

On Tue, Aug 2, 2016 at 11:38 AM, Phil White <pw...@gmail.com> wrote:
> Two years on I saw the same thing, that Spring's JMSTemplate seems to ignore
> non-persistent delivery configuration, and always sends as persistent.
> Tracing through JMSTemplate it turns out that deliveryMode, priority, and
> timeToLive are ignored during send() unless "explicit QOS" is enabled, ie.
> jmsTemplate.setExplicitQosEnabled(true). Or alternatively the equivalent in
> the Spring app context:
>
>         <bean id="jmsTemplate" class="org.springframework.jms.core.JmsTemplate">
>                 <property name="connectionFactory">
>                         <ref local="jmsFactory"/>
>                 </property>
>                 <property name="pubSubDomain" value="true"/>
>                 <property name="deliveryPersistent" value="false"/>
>                 <property name="deliveryMode" value="1"/>
>                 <property name="explicitQosEnabled" value="true"/>
>         </bean>
>
> I'm sure the OP found the same thing out years ago, but just for anyone else
> with the same problem.
>
>
>
> --
> View this message in context: http://activemq.2283324.n4.nabble.com/Non-persistent-deliverymode-not-effect-tp4680457p4714981.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.



-- 
Clebert Suconic