Per message persistence and/or time to live

[Carlos Quiroz <ca...@nokia.com>]

Hi

I have been using Camel for a while and a requirement appeared to set
certain messages as persistent while others will not. What I'd like to have
is a pipieline  of processors that end in a JMS component and the last one
can set for example headers or properties in the exchange that set the
presistent properties of the message based, e.g. on content.

I tried several ways to do this and finally manage to understand that in
order to do so you need a specific jms component where the
deliveryPersistent is set to false as follow:

	<bean id="activemq"
		class="org.apache.camel.component.jms.JmsComponent"
		p:connectionFactory-ref="jmsFactory">
	</bean>

	<bean name="activemq-np"
		class="org.apache.camel.component.jms.JmsComponent"
		p:connectionFactory-ref="jmsFactory" p:deliveryPersistent="false"
		p:explicitQosEnabled="true" p:timeToLive="60000">
	</bean>

That complicates things thing it means that I have to set that all messages
from a given processor are sent to activemq-np in order for those messages
to be not persistent. What I'd expect instead is that the processor can
decide based on certain criteria if a specific message is persistent and
what time to live you can use.

I tried to set the JMSDeliveryMode and JMSExpiration headers but they are
ignored by the JMSBinding class instead delegating that decision to
JMSComponent.

What is the rationale for this decision? Wouldn't be better that each
message can be set as persistent/non persistent depending on some criteria
rather than having to tweak your routes for this?

Any ideas?

Best Regards
Carlos Quiroz
-- 
View this message in context: http://www.nabble.com/Per-message-persistence-and-or-time-to-live-tp17397924s22882p17397924.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Re: Per message persistence and/or time to live

[Gert Vanthienen <ge...@skynet.be>]

Carlos,

They have probably been removed to avoid problems when this type of 
metadata is traveling from queue to queue when coding something like 
from("queue:1").to("queue:2").   I think it is a sensible default to 
drop these to avoid some common problems people might otherwise run into 
(e.g. deliving a message with a TTL they didn't expect just because it 
was put in the previous queue that way), but we should also have a means 
of (re)adding them explicitly on a per-message basis.  Feel free to 
raise a JIRA for this (a patch would be welcome too ;) )

Gert

Carlos Quiroz wrote:
> Hi
>
> I have been using Camel for a while and a requirement appeared to set
> certain messages as persistent while others will not. What I'd like to have
> is a pipieline  of processors that end in a JMS component and the last one
> can set for example headers or properties in the exchange that set the
> presistent properties of the message based, e.g. on content.
>
> I tried several ways to do this and finally manage to understand that in
> order to do so you need a specific jms component where the
> deliveryPersistent is set to false as follow:
>
> 	<bean id="activemq"
> 		class="org.apache.camel.component.jms.JmsComponent"
> 		p:connectionFactory-ref="jmsFactory">
> 	</bean>
>
> 	<bean name="activemq-np"
> 		class="org.apache.camel.component.jms.JmsComponent"
> 		p:connectionFactory-ref="jmsFactory" p:deliveryPersistent="false"
> 		p:explicitQosEnabled="true" p:timeToLive="60000">
> 	</bean>
>
> That complicates things thing it means that I have to set that all messages
> from a given processor are sent to activemq-np in order for those messages
> to be not persistent. What I'd expect instead is that the processor can
> decide based on certain criteria if a specific message is persistent and
> what time to live you can use.
>
> I tried to set the JMSDeliveryMode and JMSExpiration headers but they are
> ignored by the JMSBinding class instead delegating that decision to
> JMSComponent.
>
> What is the rationale for this decision? Wouldn't be better that each
> message can be set as persistent/non persistent depending on some criteria
> rather than having to tweak your routes for this?
>
> Any ideas?
>
> Best Regards
> Carlos Quiroz
>