We are using camel blueprint and jboss fuse 6 for our bundle deployment.
The problem is bundle's camel context keep restarting some times and doesn't come up automatically.
Logs are showing clearly that all the routes are coming up and then all are shutting down itself and the same activity is going on infinitely.
It is difficult to trace as it is not happening consistently.
Using camel core 2.12
I had this issue and in my blueprint the attribute update-strategy="reload" on the blueprint-cm default properties was causing this to happen. I changed this to update-strategy="none" and this fixed the restarting behaviour.
However, this broke my blueprint tests because they relied on me being able to change properties at test-run time. If you rely on changing properties in your blueprint tests then the most reliable test method to substitute properties is the recently added (in camel-test-blueprint version 2.16.3) setConfigAdminInitialConfiguration(Properties props) which you can override and return a pid like you would with useOverridePropertiesWithConfigAdmin(Dictionary props).
I'm using JBoss Fuse 6.2.1 and even though that camel version is 2.15.1, the test version is independent (because it's scoped to test) and you can set it to whichever you like. So even though you're using camel 2.12 I'd try with the 2.16.3 version of blueprint test.
Related
I want to implement some content-caching on my Camel 2.23.2 routes. While researching I came across Camel's JCache component which, according to the documentation, should have a JCachePolicy that would:
"The JCachePolicy is an interceptor around a route that caches the "result of the route" - the message body - after the route is completed. If next time the route is called with a "similar" Exchange, the cached value is used on the Exchange instead of executing the route."
Which is basically exactly what I'm looking for. However, as it turns out this policy is only available in Camel 3.x and higher.
So my question is, how might I recreate this functionality in Camel 2.23.2?
The solution was quite simple. In the Camel 3.x branch the policy package is available and in it are only two files. The actual policy and the processor.
As it turns out, pending more testing, these files work very well with little adjustment.
On the policy you need to change the method definition for the "wrap" and "beforeWrap" methods. These require the routeContext, not the Route. But moving from the RouteContext to the route is simple enough.
On the processor, the main change is using the correct package for "DelegateAsyncProcessor" it extends.
With those changes everything seemingly works as documented. I used the ehcache spring boot starter in my pom without any further change to have it work with ehcache as it's cachemanager.
One other remark, when you want to use this, the model you want to cache needs to be serializable.
The application has several camel contexts, each doing its own thing and as such do not need to communicate with each other. They are in the same module because they share some classes.
Are there any issues one needs to watch out for in the case of multiple contexts in a single osgi module ?
What is the recommendation and best-practice in this case ?
It is fairly subjective. IMHO: The two big things to consider are process control and upgrade impacts. Remember-- during a bundle upgrade all the contexts will stop and then restart.
You still have the ability to do fine grain process control (start, stop, pause, resume) at the Camel Context and Route level without having to rely on bundle start | stop.
If you wanted fine grain upgrade ability, you could put the Java classes in their own bundle, export the packages. Then put Camel Contexts in their own bundles and import the Java classes from the shared bundle. You then have the ability to do individual upgrades of the Camel Contexts w/o having to upgrade all the Contexts at once (and force them all to stop).
One single recommendation: have stateless beans/processors/aggregators.
All the state related information about the processing of your body must live in the Exchange headers/properties.
static final constants are good.
Configuration read only properties are fine too.
I'm running a Camel application on Liberty Profile server. I'm taking a message from a queue, unmarshalling, mapping then marshalling. This was working fine but now I'm getting an error that JAXBDataBinding method getContextualNamespaceMap is not found.
I think this is because there is an older version of the jar in the server libs but I don't know why it started using it.
IBM Jar: com.ibm.ws.org.apache.cxf-rt-databinding-jaxb.2.6.2_1.0.12
The issue is resolved if I switch to parent last class loading but its a very hacky way to fix it and is not a great option. Any other ideas? I'm thinking some feature or other dependency in my build may have pulled this jar in.
So it does look like getContextualNamespaceMap is only available in newer versions of the org.apache.cxf-rt-databinding-jaxb JAR than what is available in Liberty.
It might be that parentLast is the best option then. (You already know how to do this but it's documented (here). If it leads to some other issues then do follow-up with another question.
I suppose it's conceivable you might be able to look at whatever is packaged within your application and try removing a set of things and picking them up from the Liberty runtime, to avoid running in parentLast mode. E.g. if you are only referencing getContextualNamespaceMap because you have other code in your app but there is some alternative path you could have gone down entirely in the Liberty-provided modules, then in theory you could be OK.
I'm not familiar enough with the code paths in the modules in the CXF or Camel "stack" to guess whether that's a real-world likelihood though.
The javaee7 feature contained a jaxsw version that clashed with the server version. Removing the javaee7 feature has resolved this issue. Remains to be seen whether or not I will to add it back in.
I have been working with Jboss Fuse 6.1.0.redhat-379 for about a month with great results and higher productivity in EIP. Thank you very much to the community for building such a great product.
Now I am getting ready to deploy my bundles in a dev enviroment with several camel routes and even multiple camel contexts in a single bundle and I'm noticing a weird behavior regarding camel contexts JMX display. The bundle with the multiple camel contexts is only showing the first context, others contexts work fine but they are missing in camel JMX display in hawtio.
After research about this behavior I encountered with this JIRA issue https://issues.apache.org/jira/browse/CAMEL-7545 opened by Claus, describing exactly this problem and manifesting that there are Fix Versions (2.12.4, 2.13.2, 2.14.0)
AFAIK my Jboss Fuse version is distributed with camel 2.12.0.redhat-610379 version and there is a mayor 2.14.0.redhat-620031 version that supposedly will fix this issue and it will be bring many other features like json path and sql generated keys.
Is there a way to upgrade versions of camel features in Jboss Fuse?
UPDATE
There is a similar question for this topic (Updating camel version in fuse esb) accepted answer discourages trying to update the version, however, I think it should be better to permit version upgrades if they fix issues
Not a 100% on this but the rollup patches might include the 2.12 fixed versions. Install the latest patch and see if that fixes the issue.
I would like my web app to log using SLF4j and logback. However, I am using ActiveMQ - which then requires that some if its jars go in /usr/share/tomcat6/lib (this is because the queues are defined outside of the web app so the classes to support them must be at container level).
ActiveMQ 5.5+ requires SLF4j-api so that jar has to go in to. Because SLF4j is now starting it needs to have a logging library added or it will simply nop. Thus, logback-core and logback-classic go in too.
After quite some frustration I got this working well enough that I can tidy it up shortly. I needed to configure logback to use a JNDI lookup to get the context. Then it can lookup logback-kenobi.xml in my web app and have a separate configuration there.
However, I'm wondering if this is the best way to do this. For one, the context handling appears not to support the groovy format. I did have a logback.groovy in my web app that logged to console when I was developing locally (which means that Eclipse WTP works nicely) but logs to file and to Splunk Storm when everywhere else. I'm going to want to do something similar with this setup but I'm not sure if I should do that by overwriting the logback-kenobi.xml or some other method.
Note that I don't, currently, need Tomcat itself to log with slf4j although I am planning to do that. Nor do I really need ActiveMQ to log with slf4j but I did need it to stop spewing debug messages every 30s as it was doing. I am aware of tomcat-slf4j-logbak but I don't believe it is directly useful as it is ActiveMQ requiring logging which is the issue.
However, I'm wondering if this is the best way to do this.
Best is an opinion, working is a fact.