In the context of a migration from ServiceMix 5.1.4 (smx-5) to ServiceMix 7.0.1 (latest stable release) (smx-7) I can see a strange behaviour on my camel routes using the cxf:RsServer
My Camel route looks like this:
from("cxfrs:bean:rsServer?bindingStyle=SimpleConsumer&synchronous=true")
.setBody(simple("${body[0]}"))
.marshal(df)
.convertBodyTo(String.class)
.to("{{user.request.endpoint}}")
.process(checkResponseStatusCode())
.unmarshal(df);
and in the blueprint I have:
<cxf:rsServer id="rsServer" address="/user-data/v1"
loggingFeatureEnabled="true" depends-on="user-rest-v1"
serviceClass="org.my.company.user.rest.v1.resources.UserDataServiceRest"
staticSubresourceResolution="true">
<cxf:providers>
<bean name="jacksonJsonProvider" class="com.fasterxml.jackson.jaxrs.json.JacksonJsonProvider" />
<ref component-id="authenticationFilter" />
</cxf:providers>
<cxf:properties>
<entry key="binding">
<ref component-id="mySecurityCxfRsBinding" />
</entry>
</cxf:properties>
</cxf:rsServer>
The class UserDataServiceRest contains the method signature and returning null as per old camel specification.
I know it now supports Interface but I am not sure that could be the cause of my issue.
I the version smx-5 all bundles are starting in few seconds (per bundle). In smx-7 the same bundles starts in at least 2 min (per bundle).
While it takes so long, I do not see any activity in the logs.
Note that I also have the issue with server like this:
<jaxrs:server id="pingServiceSvc" address="/ping">
<jaxrs:serviceBeans>
<ref component-id="pingServiceBean" />
</jaxrs:serviceBeans>
<jaxrs:providers>
<ref component-id="commonExceptionHandler" />
</jaxrs:providers>
<jaxrs:inInterceptors>
<ref component-id="requiredParametersInterceptorBean" />
</jaxrs:inInterceptors>
</jaxrs:server>
which just answers OK for any reqquest (ping service).
My settings:
UPDATE
When I tried locally (CentOS 6.10) the bundle (exposing CXF server) starts in around 20 seconds. But when it's deployed on the real server (RHEL 7) it takes more than 2 mins. I suspect a network issue but there's nothing in the logs. The configuration is almost the same... I am looking into it.
I found the solution.
What drives me to the solution was these Warning messages in my logs:
2019-06-27T09:24:24Z | WARN | NamespaceHandlerRegistryImpl | 34 | NamespaceHandler org.apache.camel.blueprint.handler.CamelNamespaceHandler is behaving badly and should be fixed | | |
2019-06-27T09:24:24Z | WARN | NamespaceHandlerRegistryImpl | 34 | NamespaceHandler org.apache.camel.component.cxf.blueprint.CxfNamespaceHandler is behaving badly and should be fixed | | |
2019-06-27T09:24:24Z | DEBUG | BlueprintContainerImpl | 34 | Running blueprint container for bundle com.mycompany.user.user-rest-v1/1.0.1.SNAPSHOT in state WaitForNamespaceHandlers | | |
2019-06-27T09:24:24Z | WARN | NamespaceHandlerRegistryImpl | 34 | Unable to find namespace handler for http://cxf.apache.org/configuration/beans | | |
It seems there is a problem in the namespace handler in CXF and probably as my server cannot access Internet, there is a timeout.
At this point these was only speculations.
After searching a bit about this subject on Internet, I found this jira which seems to have a fix in higher version of Camel (since 2.18 and 2.19 according to the JIRA ticket).
Unfortunately there is no more stable release of ServiceMix with a more recent version of Camel than 2.16.5.
Then I tried to upgrade my ServiceMix 7.0.1 with a more recent version of Camel: 2.23.0 (I also tried with 2.24.1 but many of my OSGI dependencies get broken.)
The change I applied is:
in file org.apache.karaf.features.cfg
changed the line: mvn:org.apache.camel.karaf/apache-camel/2.16.5/xml/features, \
with: mvn:org.apache.camel.karaf/apache-camel/2.23.0/xml/features, \
in file profile.cfg.erb
changed the line: repository.mvn\:org.apache.camel.karaf/apache-camel/2.16.5/xml/features = mvn:org.apache.camel.karaf/apache-camel/2.16.5/xml/features
with: repository.mvn\:org.apache.camel.karaf/apache-camel/2.23.0/xml/features = mvn:org.apache.camel.karaf/apache-camel/2.23.0/xml/features
After that, * stop your ServiceMix * clean cache folder * start the ServiceMix
( or restart the servicemix with clean option)
After the full start, when I re-install my feature, all bundles started in a smooth way and faster than before.
Conclusion: the SM-3390 was probably the reason why the bundles were starting slowly.