Camel Blueprint - Gave up waiting for Service exception

Question

I have a bunch of unit tests that test some routing/camel implementation in Blueprint. These test run absolutely fine 95% of the time however every so often (1 in 20 or so) I get a Camel Runtime exception:

I am running the latest version of Fabric8 with Camel 2.12

java.lang.RuntimeException: Gave up waiting for service (objectClass=org.apache.camel.CamelContext)
    at org.apache.camel.test.blueprint.CamelBlueprintHelper.getOsgiService(CamelBlueprintHelper.java:240)
    at org.apache.camel.test.blueprint.CamelBlueprintHelper.getOsgiService(CamelBlueprintHelper.java:198)
    at org.apache.camel.test.blueprint.CamelBlueprintTestSupport.createCamelContext(CamelBlueprintTestSupport.java:304)
    at org.apache.camel.test.junit4.CamelTestSupport.doSetUp(CamelTestSupport.java:247)
    at org.apache.camel.test.junit4.CamelTestSupport.setUp(CamelTestSupport.java:217)
    at org.apache.camel.test.blueprint.CamelBlueprintTestSupport.setUp(CamelBlueprintTestSupport.java:133)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:606)
    at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
    at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
    at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
    at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
    at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
    at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
    at org.junit.rules.RunRules.evaluate(RunRules.java:20)
    at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
    at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
    at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
    at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
    at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
    at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
    at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
    at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
    at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
    at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
    at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
    at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
    at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
    at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
    at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
    at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)

Tests in error: 
  SystemStatusRouteBuilderTest>CamelBlueprintTestSupport.setUp:133->CamelTestSupport.setUp:217->CamelTestSupport.doSetUp:247->CamelBlueprintTestSupport.createCamelContext:304 » Runtime

I've triple checked all namespaces in the blueprint file, the pom is packaged as a bundle, the blueprint file is located in the expected location: src/main/resources/OSGI-INF/blueprint/blueprint.xml, and I have the camel maven plugin specified as so:

<plugin>
   <groupId>org.apache.camel</groupId>
   <artifactId>camel-maven-plugin</artifactId>
   <version>${camel.version}</version>
   <configuration>
      <useBlueprint>true</useBlueprint>
   </configuration>
</plugin>

Any ideas as to why this might be happening? Its very difficult to debug due to its intermittent nature.

Answer 1

I came accross the same the issue (inside a JUnit test) and finally found the reason. When enabling the full Camel traces, I could see the following message:

"Bundle **** is waiting for dependencies [(&(component=ldap)(objectClass=org.apache.camel.spi.ComponentResolver)), (&(component=sql)(objectClass=org.apache.camel.spi.ComponentResolver))] "

This lead me to add the explicit (test) dependency in my pom, ie:

<dependency>
  <groupId>org.apache.camel</groupId>
  <artifactId>camel-sql</artifactId>
  <version>${camel-version}</version>
 <scope>test</scope>
</dependency>

NB: to do for all components (jaxb, ldap, sql, cache, etc...) you used in your Camel routes !

This made my error message ("Gave up waiting for Service exception") disappear :-)

Hope this helps.

Answer 2

This is a common issue with CamelBlueprintTestSupport.

See comment from Claus here - http://fusesource.com/forums/thread.jspa?threadID=4695

Yeah I have seen this from time to time as well. You can run the tests 100 times, and it may fail a few times etc. Not sure what happens, if its pojosr or blueprint etc. Though OSGi and Blueprint has a really complicated startup model where all is async, and kinda waiting for each other. And that is dead hard to test throughly.

You can try setting the surefire plugin to fork the jvm per test. Then its a full fresh JVM on each test. This may fix this, in case there is some "left over" when running all the test in the same JVM.

I have experienced this issue myself as well

Answer 3

I faced a similar issue in my project. The root cause is usually the dependency. Steps you can try to find the root cause:

1) Remove your project dependencies and just use camel-test-blueprint to run a basic scenario from: http://camel.apache.org/blueprint-testing.html

2) It should work fine ideally :). Now slowly start adding your project dependencies one by one and test your actual scenario (not the one i mentioned above). At one point of time, it would break. If it breaks, you have to avoid using that dependency. If you can't, find another way to run your test i.e. using separate project for test etc...

If you debug the CamelBlueprintTestSupport, you will get yourself lost in it. As Matthew mentioned, it is difficult to debug async flow. Try my steps and believe me it would work. I did the same.