Testcontainers-java: Mock Server doesn't start after updating to 5.11.0

Created on 9 Jul 2020  路  4Comments  路  Source: testcontainers/testcontainers-java

Hi folks!

I'm raising this here although it may be related to the Mock Server. We're having issues when updating to the latest version of the Mock Server and its Java client (5.11.0) with Testcontainers.

The Problem

We use Testcontainer's MockServerContainer which starts the jamesdbloom/mockserver container, something like:

@Container
static MockServerContainer mockServerContainer = new MockServerContainer("5.11.0"));

The container doesn't seem to start and the build/tests time out waiting for it:

2020-07-09T17:16:36.590+0100 ERROR  [main] ?.11.0] - Could not start container org.testcontainers.containers.ContainerLaunchException: Timed out waiting for container port to open (localhost ports: [33023] should be listening)

This is working fine in 5.10.0.

Potential Solution

The bit that seems to cause the issue is the addExposedPorts call in the MockServerContainer. I created a custom class with the same logic but without it and solves the problem.
I've also tested it in 5.10.0 and works fine. Is this a reasonable workaround and is there any reason why this call was/is needed?

Thanks :)

resolutioacknowledged

Most helpful comment

Thanks @vcvitaly and apologies for not coming back.

I had a look at this today and the issue has to do with the wait strategy. The default wait strategy worked until 5.10.0 but for 5.11.0 I needed to provide a WaitStrategy that's based on an HTTP endpoint.

@Container
static MockServerContainer mockServerContainer = new MockServerContainer("5.11.0")
    .withEnv("MOCKSERVER_LIVENESS_HTTP_GET_PATH", "/health")
    .waitingFor(Wait.forHttp("/health").forStatusCode(200));

As regards the MOCKSERVER_LIVENESS_HTTP_GET_PATH, by default Mock Server exposes a PUT health/live check and so I provided a custom GET one, as explained in the docs.

With that it now works ok.

All 4 comments

I can reproduce it, the reason it fails is:

OCI runtime exec failed: exec failed: container_linux.go:349: starting container process caused "exec: \"/bin/sh\": stat /bin/sh: no such file or directory": unknown

On startup Testcontainers runs a command in container to verify the status and starting 5.11.0 Mockserver image doesn't contain /bin/sh.

It's also a good question why nothing is logged in InternalCommandPortListeningCheck in case of such error.

@bsideup I described the issue in the PR, could you please advice if such improvement would make sense? It's a rare case.

A simple test to reproduce:

public class SomeTest {
    @Test
    public void test_5_11() {
        MockServerContainer mockServerContainer = new MockServerContainer("5.11.0").withStartupTimeout(Duration.ofSeconds(10));
        mockServerContainer.start();
        System.out.println(mockServerContainer);
    }

    @Test
    public void test_5_10() {
        MockServerContainer mockServerContainer = new MockServerContainer("5.10.0");
        mockServerContainer.start();
        System.out.println(mockServerContainer);
    }
}

@nikos912000 I'm not sure, but there seems to be a problem with 5.11.0 image, trying to connect to container causes:
OCI runtime exec failed: exec failed: container_linux.go:349: starting container process caused "exec: \"/bin/sh\": stat /bin/sh: no such file or directory": unknown

Thanks @vcvitaly and apologies for not coming back.

I had a look at this today and the issue has to do with the wait strategy. The default wait strategy worked until 5.10.0 but for 5.11.0 I needed to provide a WaitStrategy that's based on an HTTP endpoint.

@Container
static MockServerContainer mockServerContainer = new MockServerContainer("5.11.0")
    .withEnv("MOCKSERVER_LIVENESS_HTTP_GET_PATH", "/health")
    .waitingFor(Wait.forHttp("/health").forStatusCode(200));

As regards the MOCKSERVER_LIVENESS_HTTP_GET_PATH, by default Mock Server exposes a PUT health/live check and so I provided a custom GET one, as explained in the docs.

With that it now works ok.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you believe this is a mistake, please reply to this comment to keep it open. If there isn't one already, a PR to fix or at least reproduce the problem in a test case will always help us get back on track to tackle this.

Was this page helpful?
0 / 5 - 0 ratings