Unable to use static MySqlContainer in multiple test classes

[phillipjohnson]

The example here suggests that a container can be created in an abstract class and used by multiple test classes. While this is possible with the redis container, it is not with a MySqlContainer.

public abstract class AbstractIntegrationTest {
    @ClassRule
    public static MySQLContainer mysql = new MySQLContainer();
}

public class ExampleTestOne extends AbstractIntegrationTest {
    @Test
    public void someTest() {
        assertTrue(true);
    }
}

public class ExampleTestTwo extends AbstractIntegrationTest {
    @Test
    public void someTest() {
        assertTrue(true);
    }
}

One test passes, but the second fails due to "Duplicate mount point '/etc/mysql/conf.d'".

Complete stack trace:

org.testcontainers.containers.ContainerLaunchException: Container startup failed

	at org.testcontainers.containers.GenericContainer.start(GenericContainer.java:189)
	at org.testcontainers.containers.GenericContainer.starting(GenericContainer.java:544)
	at org.testcontainers.containers.FailureDetectingExternalResource$1.evaluate(FailureDetectingExternalResource.java:29)
	at org.junit.rules.RunRules.evaluate(RunRules.java:20)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
	at org.junit.runners.Suite.runChild(Suite.java:128)
	at org.junit.runners.Suite.runChild(Suite.java:27)
	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
	at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
	at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
	at com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:51)
	at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
	at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
Caused by: org.rnorth.ducttape.RetryCountExceededException: Retry limit hit with exception
	at org.rnorth.ducttape.unreliables.Unreliables.retryUntilSuccess(Unreliables.java:83)
	at org.testcontainers.containers.GenericContainer.start(GenericContainer.java:182)
	... 17 more
Caused by: org.testcontainers.containers.ContainerLaunchException: Could not create/start container
	at org.testcontainers.containers.GenericContainer.tryStart(GenericContainer.java:256)
	at org.testcontainers.containers.GenericContainer.lambda$start$0(GenericContainer.java:184)
	at org.testcontainers.containers.GenericContainer$$Lambda$35/1728579441.call(Unknown Source)
	at org.rnorth.ducttape.unreliables.Unreliables.retryUntilSuccess(Unreliables.java:76)
	... 18 more
Caused by: java.lang.reflect.UndeclaredThrowableException
	at com.sun.proxy.$Proxy13.exec(Unknown Source)
	at org.testcontainers.containers.GenericContainer.tryStart(GenericContainer.java:206)
	... 21 more
Caused by: java.lang.reflect.InvocationTargetException
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:483)
	at org.testcontainers.dockerclient.AuditLoggingDockerClient.lambda$wrappedCommand$14(AuditLoggingDockerClient.java:98)
	at org.testcontainers.dockerclient.AuditLoggingDockerClient$$Lambda$28/1971764991.invoke(Unknown Source)
	... 23 more
Caused by: com.github.dockerjava.api.exception.InternalServerErrorException: {"message":"Duplicate mount point '/etc/mysql/conf.d'"}

	at com.github.dockerjava.netty.handler.HttpResponseHandler.channelRead0(HttpResponseHandler.java:109)
	at com.github.dockerjava.netty.handler.HttpResponseHandler.channelRead0(HttpResponseHandler.java:33)
	at org.testcontainers.shaded.io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
	at org.testcontainers.shaded.io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
	at org.testcontainers.shaded.io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
	at org.testcontainers.shaded.io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
	at org.testcontainers.shaded.io.netty.handler.logging.LoggingHandler.channelRead(LoggingHandler.java:241)
	at org.testcontainers.shaded.io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
	at org.testcontainers.shaded.io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
	at org.testcontainers.shaded.io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
	at org.testcontainers.shaded.io.netty.channel.CombinedChannelDuplexHandler$DelegatingChannelHandlerContext.fireChannelRead(CombinedChannelDuplexHandler.java:438)
	at org.testcontainers.shaded.io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:310)
	at org.testcontainers.shaded.io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:284)
	at org.testcontainers.shaded.io.netty.channel.CombinedChannelDuplexHandler.channelRead(CombinedChannelDuplexHandler.java:253)
	at org.testcontainers.shaded.io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
	at org.testcontainers.shaded.io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
	at org.testcontainers.shaded.io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
	at org.testcontainers.shaded.io.netty.handler.logging.LoggingHandler.channelRead(LoggingHandler.java:241)
	at org.testcontainers.shaded.io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
	at org.testcontainers.shaded.io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
	at org.testcontainers.shaded.io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
	at org.testcontainers.shaded.io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1334)
	at org.testcontainers.shaded.io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
	at org.testcontainers.shaded.io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
	at org.testcontainers.shaded.io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:926)
	at org.testcontainers.shaded.io.netty.channel.kqueue.AbstractKQueueStreamChannel$KQueueStreamUnsafe.readReady(AbstractKQueueStreamChannel.java:608)
	at org.testcontainers.shaded.io.netty.channel.kqueue.KQueueDomainSocketChannel$KQueueDomainUnsafe.readReady(KQueueDomainSocketChannel.java:127)
	at org.testcontainers.shaded.io.netty.channel.kqueue.AbstractKQueueChannel$AbstractKQueueUnsafe.readReady(AbstractKQueueChannel.java:355)
	at org.testcontainers.shaded.io.netty.channel.kqueue.KQueueEventLoop.processReady(KQueueEventLoop.java:198)
	at org.testcontainers.shaded.io.netty.channel.kqueue.KQueueEventLoop.run(KQueueEventLoop.java:270)
	at org.testcontainers.shaded.io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:858)
	at org.testcontainers.shaded.io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:138)
	at java.lang.Thread.run(Thread.java:744)

This is on Docker Community Edition for Mac using testcontainers 1.4.1.

Version 17.06.0-ce-mac18 (18433)
Channel: stable
d9b66511e0

[kiview]

There might be some race condition which would lead to multiple MySql containers being running simultaneously, something that the current implementation of MySQLContainer does not allow.
A temporary workaround would involve omitting the @ClassRule annotation and starting/stopping the container manually in the @BeforeClass method.

[bsideup]

Hi @phillipjohnson,

Thanks for reporting! It's some weird behavior in JUnit I don't really understand.

However, you can remove @ClassRule and replace it with:

public abstract class AbstractIntegrationTest {

    public static MySQLContainer mysql = new MySQLContainer();

    static {
        mysql.start();
    }
}

by doing this, you will get a singleton-like MySQL container, and it will be destroyed at JVM shutdown :)

[phillipjohnson]

Thanks for the suggestion! it seems that using @ClassRule does try to create the container twice. I noticed when using a Tomcat container that the exposed port actually changed between initialization in AbstractIntegrationTest and the actual test I was running. Using the static initializer worked fine, though.

[rnorth]

Aha, so effectively JUnit triggers startup more than one time on the same object? (It is the same object, because it's a static member of the parent class)

This is kinda obscure, but perhaps we should have some guard code to at least detect where a container is started more than once without being stopped in between. That way we could log a more useful message!!

[kiview]

Great idea, sounds super helpful 😃 (I had the same problem with testcontainers-spock btw. and we found out about it because of MySQLContainer, but it was a bug in my code 😉, would have found it earlier with such an error message as well)

[dyabluchanskyi]

Hello guys, I wonder if there any solution for this issue so far? We do use MySQL and we've been really amazed with testcontainers, but we do have the problem described above.

[bsideup]

Hi @diabluchanskyi

Please see my previous comment:
#417 (comment)

[bsideup]

@diabluchanskyi you might also consider JDBC URLs:
https://www.testcontainers.org/usage/database_containers.html#jdbc-url

[dyabluchanskyi]

@bsideup Thank you, it works with 1st proposed solution

[unhuman]

In addition to the suggestion that @bsideup suggested above, for Couchbase (https://github.com/differentway/testcontainers-java-module-couchbase), I also needed to add a wrapper around the Container object:

    /**
     * This class is to allow the CouchbaseContainer to be shared across tests
     * When the JVM shuts down, the container will as well
     */
    public class TestingCouchbaseContainer extends CouchbaseContainer {
        private static AtomicBoolean started = new AtomicBoolean(false);

        @Override
        public void start() {
            // only allow a single start()
            if (started.compareAndSet(false, true)) {
                super.start();
            }
        }

        @Override
        public void stop() {
            // Do nothing
        }
    }

[bsideup]

Hi @unhuman,

Did you try static {} block approach? You don't need that wrapper with it

[unhuman]

@bsideup Indeed I did. That's why I mentioned it... In case other people find they have the same problem.

[guss77]

@phillipjohnson - It is not a race condition or anything: this problem is caused by having the class rule set on a base class for the tests, instead of on the test itself. Move the MySQL container to a class rule on each test, and the problem goes away.

The confusion is because of a misunderstanding of how static fields work in OO, and I see this a lot: if you have a static field on a parent class, which you sub-class 3 times, how many copies of that object do you have? Exactly one.

When JUnit runs the class rule, it doesn't know (nor care) that the field is not stored in the test class itself, and it will run the rule again for each class. The single MySQL container isn't being run multiple times concurrently (at least not if you use the classic non-parallel JUnit runner), but it is trying to call start() on a MySQLContainer that was already stopped - and this is what causes the errors.

My solution was to simply move the container rule to each test, though a possible solution might also be to leave it on the base class and write an @AfterClass method (in the base class) that will throw away the used container and prime a new one for the next class:

@AfterClass
public void recycleDatabase() {
    mysql = new MySQLContainer(); // replace used database with a fresh one
}

I haven't actually tried that (it feels hackish to me), so YMMV - and it will for sure not work if you are using a parallel runner.

[bsideup]

@guss77 for the same use case (shared MySQL between different test classes) we use the approach I mentioned in one of my previous comments:
#417 (comment)

It works like a charm and from TestContainers' perspective is absolutely fine to use, I promise (c) :D