How do you set the TTL for a message when using Java DSL?
I have something like this:
...
from ("timer:something?delay=3000&period=15000")
...
.to("{{some.property}}")
.end()
...
I want to set a time to live on the message being sent.
I ended up setting the JMSExpiration header field of the messages being created similar to the following
.setHeader("JMSExpiration", constant(System.currentTimeMillis() + 1000))
We are using Apache ActiveMQ 5.7.
I assume TTL means Time to Live.
In Camel this is component specific how they deal with this. Some components support this, and others do not.
You should check the documentation for the component you use, what it supports.
If you use JMS component then it has the timeToLive option as documented: http://camel.apache.org/jms
And mind about the problem with "client and server clock's can be out of sync". There is some details on the Camel JMS page. Some message brokers has ways to sync the clocks, such as Apache ActiveMQ with its timestamp plugin: http://activemq.apache.org/timestampplugin.html
Related
How transacted() in camel DSL is related to transacted="true" of JMSComponent.
Will that make any sense, if transacted property of JMSComponent is set to "true" along with transacted() in camel DSL ?
transacted="true" in JMS component configuration makes your JMS consumer transacted. So this is required if you want to make sure you don't lose messages.
However, you have multiple options to enable transactions (see the Camel docs for details).
Use local JMS transactions
Use your own Spring transaction manager
The Camel DSL transacted() is only necessary if you go with the second option, it references a SpringTransactionPolicy (for example PROPAGATION_REQUIRED). If it is present in your route, Camel is looking for a Spring transaction manager to use.
If you use option 1 (what is simpler in configuration and perfectly suitable if you only talk to a single JMS broker), you don't need the Camel DSL transacted() and your JMS consumer routes are nevertheless transactional.
Addition due to comments
To use option 1, you only have to set transacted="true" and lazyCreateTransactionManager="false" on your Camel ActiveMQComponent. You must not configure a Spring transaction manager (if you do, you end up with two tx managers!)
If you want to be transactional between multiple JMS brokers or a broker and a Database, you would either need XA transactions or you have to implement compensation logic to handle the edge cases when using simple transactions with each system involved.
How can I determine what, if any, ActiveMQ queue a camel route is a consumer of? The route is running as a bundle within Karaf.
You have to define it yourself. Every Camel route starts with a from statement. For ActiveMQ this would look somehow like this
from("activemq:queue:myAwesomeQueue")...
This route would create an ActiveMQ consumer that consumes every message arriving on the myAwesomeQueue.
The connection to the broker is "hidden" behind the activemq:. This is a Camel component (the ActiveMQ component) that needs to be configured to connect to the broker.
EDIT: Add operational perspective
Hawtio is a webconsole that uses Jolokia to get data. Jolokia makes JMX information available through a REST API.
If JMX is enabled, you can get loads of information about the CamelContext and/or ActiveMQ. For example the endpoint of an ActiveMQ consumer as in your case.
Unfortunately I can't upload a screenshot because the image domain of SO is blocked, but Google gives you lots of them.
Some AMQP enabled brokers like Microsoft Service Bus or ActiveMQ allow only one active producer or consumer per session. The Apache JMS Camel component seems not be able to handle this correctly, which result that JMS throws exceptions when processing InOut messages sent from e.g. Service Bus.
A small JMS test application with separate sessions for producer and consumer works nice. With using the same session, it run into the same problem.
Issue is rooted in the Spring JMS template, which is used as base for the Camel JMS implementation.
Does anybody know how to overcome that behavior?
You can define a 2nd JMS component and use that for the "other".
Or you can turn off any kind of connection pooling maybe.
If you use XML then you can define a 2nd jms component
<bean id="jms2" class="org.apache.camel.component.jms.JmsComponent"/>
What's the best strategy to send SMS via SMPP with Camel ? Should I use the ProducerTemplate ?
I'm new to camel so I'm not confident if my strategy is the best.
In my application upon reception of an SMS, I have to send back an other SMS with some computed content.
I created a
route smsIn that looks like this
from "uri=smpp ..."
unmarshal ref="bindyDataFormat"
to "uri=bean:myBean
and a route smsOut with
from "uri=direct:smsOut"
to "uri=smpp ..."
The smsIn route, receives the sms, transforms its conent (csv data) in a pojo and send that pojo to myBean.
In myBean I do some processing and then call a ProducerTemplate which send my computed message to the endpoint "direct:smsOut".
The reason I use the producerTemplate is that I have to set some info from my pojo in the header (CamelSmppDestAddr) and the body of the Exchange.
I have tested with the logica SMSC simulator, this seems to work fine, but would like to have your opinion about this solution ?
What about reliability , transaction ?
Should I store my message before trying to send it to the SMSC ?
Should I store it in a database, post it to a queue ?
I'm not sure why you have a producer template, you could just build up the route instead (given that you return something from your bean or takes an Exchange as paramter).
<from uri="smpp: ..."/>
<bean ref="bean:myBean"/>
<to uri="jms:queue:myQueue"/>
then not use direct, but use a JMS queue that is transactional and persistent. Say your smpp call fails, the message would have been gone. Using a queue like this and make sure its transactional, you can make sure not to lose data in this stage of the route.
<from uri="jms:queue:myQueue"/>
<transactional/>
<to uri="smpp.."/>
I suggest using Apache ActiveMQ as JMS middleware. Actually, if you download ActiveMQ, you get camel bundled, so you could actually run your Camel routes from ActiveMQ.
You might want to tweak how retries and error handling occurs dependent on what you want to happen (retry every second forever?, retry five times, then put to error queue? etc).
Read this page: Transaction Error handling in Camel
For deeper info and more tweaks, you might also want to read this:
Transactional Client
First of all thanks to folks who are currently involved in the development of Camel, I am grateful for all the hard work they have put in.
I am looking for some design advice.
The architecture is something like this:
I have a bunch of Java classes which when instantiated are required to connect to each other and send messages using Apache Camel. The design constraints require me to create a framework such that all routing information, producers, consumers, endpoints etc should be a part of the camel-context.xml.
An individual should have the capability to modify such a file and completely change the existing route without having the Java code available to him.(The Java code would not be provided, only the compiled Jar would be)
For example in One setup,
Bean A ->Bean B->Bean C->file->email.
in another
Bean B->Bean A->Bean C->ftp->file->email
We have tried various approached, but if the originating bean is not implemented as a Java DSL, the messages rate is very high because camel constantly invokes Bean A in the first example and Bean B in the second(they being the source).
Bean A and Bean B originate messages and are event driven. In case the required event occurs, the beans send out a notification message.
My transformations are very simple and I do not require the power of Java DSL at all.
To summarize, I have the following questions:
1) Considering the above constraints, I do I ensure all routing information, including destination addresses, everything is a part of the camel context file?
2) Are there example I can look at for keeping the routing information completely independent of the java code?
3) How do I ensure Camel does not constantly invoke the originating bean?
4) Does Camel constantly invoke just the originating bean or any bean it sends & messages to irrespective of the position of the bean in the entire messaging queue?
I have run out of options trying various ways to set this up. Any help would be appreciated.
Read about hiding the middleware on the Camel wiki pages. This allows you to let clients use an interface to send/receive messages but totally unaware of Camel (no Camel API used at all).
Even better consider buying the Camel in Action book and read chapter 14 which talks about this.
http://www.manning.com/ibsen/
Save 41% on Manning books: Camel in Action or ActiveMQ in Action. Use code s2941. Expires 6th oct. http://www.manning.com/ibsen/
If you consider using ServiceMix of FuseESB, you might want to separate your routes in two parts.
First part would be the Event-driver bean that trigger the route. It could push messages to the ServiceNMR (see http://camel.apache.org/nmr.html).
The other part would be left to the framework users, using Spring DSL. It would just listen to message on the NMR (push by the other route) and do whatever they want with it.
Of course endpoint definition could be propertized using servicemix configuration service (see http://camel.apache.org/properties.html#Properties-UsingBlueprintpropertyplaceholderwithCamelroutes)