Mulesoft build gives a 'LifecycleException: failed to invoke lifecycle phase "start"' on DefaultHttpListenerConfig with a 'BindException address already in use' only on our CI / CD server.
The corresponding build and munits succeed locally, but as soon as svn triggers a bamboo / artifactory build on the build server the errors (below) occur even before munits are run ('Tests: 0'), so it seems to be on pre-invocation of tests.
There is no HTTP listener that I have defined called DefaultHttpListenerConfig and I changed all ports in mule-app.properties to localhost (even as munits were mocking all HTTP endpoints).
Build failure messages:
java.lang.RuntimeException: org.mule.api.lifecycle.LifecycleException: Failed to invoke lifecycle phase "start" on object: org.mule.module.http.internal.listener.DefaultHttpListenerConfig@2f07930a
build 28-Mar-2017 12:11:06 at org.mule.munit.runner.simple.MunitSimpleRunner.run(MunitSimpleRunner.java:54)
build 28-Mar-2017 12:11:06 at org.mule.munit.remote.path.ApplicationPathBuilder.buildApplicationPaths(ApplicationPathBuilder.java:80)
build 28-Mar-2017 12:11:06 at org.mule.munit.remote.path.ApplicationPathBuilder.getFlowPaths(ApplicationPathBuilder.java:41)
build 28-Mar-2017 12:11:06 at org.mule.munit.remote.CoverageManager.generateCoverageReport(CoverageManager.java:82)
build 28-Mar-2017 12:11:06 at org.mule.munit.remote.RemoteRunner.calculateCoverageIfApplicable(RemoteRunner.java:119)
build 28-Mar-2017 12:11:06 at org.mule.munit.remote.RemoteRunner.run(RemoteRunner.java:65)
build 28-Mar-2017 12:11:06 at org.mule.munit.remote.RemoteRunner.main(RemoteRunner.java:39)
build 28-Mar-2017 12:11:06 Caused by: org.mule.api.lifecycle.LifecycleException: Failed to invoke lifecycle phase "start" on object: org.mule.module.http.internal.listener.DefaultHttpListenerConfig@2f07930a
build 28-Mar-2017 12:11:06 at org.mule.lifecycle.phases.DefaultLifecyclePhase.applyLifecycle(DefaultLifecyclePhase.java:249)
build 28-Mar-2017 12:11:06 at org.mule.lifecycle.RegistryLifecycleCallback.doApplyLifecycle(RegistryLifecycleCallback.java:99)
build 28-Mar-2017 12:11:06 at org.mule.lifecycle.RegistryLifecycleCallback.onTransition(RegistryLifecycleCallback.java:71)
build 28-Mar-2017 12:11:06 at org.mule.lifecycle.RegistryLifecycleManager.invokePhase(RegistryLifecycleManager.java:155)
build 28-Mar-2017 12:11:06 at org.mule.lifecycle.RegistryLifecycleManager.fireLifecycle(RegistryLifecycleManager.java:126)
build 28-Mar-2017 12:11:06 at org.mule.registry.AbstractRegistryBroker.fireLifecycle(AbstractRegistryBroker.java:88)
build 28-Mar-2017 12:11:06 at org.mule.registry.MuleRegistryHelper.fireLifecycle(MuleRegistryHelper.java:141)
build 28-Mar-2017 12:11:06 at org.mule.lifecycle.MuleContextLifecycleManager$MuleContextLifecycleCallback.onTransition(MuleContextLifecycleManager.java:91)
build 28-Mar-2017 12:11:06 at org.mule.lifecycle.MuleContextLifecycleManager$MuleContextLifecycleCallback.onTransition(MuleContextLifecycleManager.java:87)
build 28-Mar-2017 12:11:06 at org.mule.lifecycle.MuleContextLifecycleManager.invokePhase(MuleContextLifecycleManager.java:69)
build 28-Mar-2017 12:11:06 at org.mule.lifecycle.MuleContextLifecycleManager.fireLifecycle(MuleContextLifecycleManager.java:61)
build 28-Mar-2017 12:11:06 at org.mule.DefaultMuleContext.start(DefaultMuleContext.java:311)
build 28-Mar-2017 12:11:06 at org.mule.munit.runner.MuleContextManager.startMule(MuleContextManager.java:77)
build 28-Mar-2017 12:11:06 at org.mule.munit.runner.MuleContextManager.startMule(MuleContextManager.java:71)
build 28-Mar-2017 12:11:06 at org.mule.munit.runner.simple.MunitSimpleRunner.run(MunitSimpleRunner.java:47)
build 28-Mar-2017 12:11:06 ... 6 more
build 28-Mar-2017 12:11:06 Caused by: java.net.BindException: Address already in use: bind
build 28-Mar-2017 12:11:06 at sun.nio.ch.Net.bind0(Native Method)
build 28-Mar-2017 12:11:06 at sun.nio.ch.Net.bind(Net.java:433)a
This exception is thrown because your mule test configuration is using a port that is already used on your bamboo server. Can you run this command on your bamboo server? Replace of course 80 with the port that your tests are using
sudo netstat -plnt | grep ':80'
If you get the command prompt response is something like this:
tcp 0 0 :::80 :::* LISTEN 8448/httpd
It means the port is already taken in which case you should use another port for your test configuration.