High CPU usage when JDBC driver not found

[ruseel]

Almost similar with #230, but In this case symptom is high CPU usage(smashing InspectContainerCmdExec).

2019-04-10 16:30:12.006 DEBUG   --- [     ducttape-0] c.g.d.core.exec.InspectContainerCmdExec  : GET: OkHttpWebTarget(okHttpClient=org.testcontainers.shaded.okhttp3.OkHttpClient@53d102a2, baseUrl=http://docker.socket/, path=[/containers/f949e1eaf71732d083b7ac8751210643c379ec434f77fde806518aeda2eb8a35/json], queryParams={})
2019-04-10 16:30:12.010 TRACE   --- [     ducttape-0] o.r.ducttape.unreliables.Unreliables     : Retrying lambda call on attempt 1159
2019-04-10 16:30:12.010 DEBUG   --- [     ducttape-0] c.g.d.core.command.AbstrDockerCmd        : Cmd: f949e1eaf71732d083b7ac8751210643c379ec434f77fde806518aeda2eb8a35,false,com.github.dockerjava.core.exec.InspectContainerCmdExec@2cd79a32
2019-04-10 16:30:12.010 DEBUG   --- [     ducttape-0] c.g.d.core.exec.InspectContainerCmdExec  : GET: OkHttpWebTarget(okHttpClient=org.testcontainers.shaded.okhttp3.OkHttpClient@53d102a2, baseUrl=http://docker.socket/, path=[/containers/f949e1eaf71732d083b7ac8751210643c379ec434f77fde806518aeda2eb8a35/json], queryParams={})
2019-04-10 16:30:12.014 TRACE   --- [     ducttape-0] o.r.ducttape.unreliables.Unreliables     : Retrying lambda call on attempt 1160
2019-04-10 16:30:12.014 DEBUG   --- [     ducttape-0] c.g.d.core.command.AbstrDockerCmd        : Cmd: f949e1eaf71732d083b7ac8751210643c379ec434f77fde806518aeda2eb8a35,false,com.github.dockerjava.core.exec.InspectContainerCmdExec@598e1db8
2019-04-10 16:30:12.015 DEBUG   --- [     ducttape-0] c.g.d.core.exec.InspectContainerCmdExec  : GET: OkHttpWebTarget(okHttpClient=org.testcontainers.shaded.okhttp3.OkHttpClient@53d102a2, baseUrl=http://docker.socket/, path=[/containers/f949e1eaf71732d083b7ac8751210643c379ec434f77fde806518aeda2eb8a35/json], queryParams={})
2019-04-10 16:30:12.019 TRACE   --- [     ducttape-0] o.r.ducttape.unreliables.Unreliables     : Retrying lambda call on attempt 1161
2019-04-10 16:30:12.019 DEBUG   --- [     ducttape-0] c.g.d.core.command.AbstrDockerCmd        : Cmd: f949e1eaf71732d083b7ac8751210643c379ec434f77fde806518aeda2eb8a35,false,com.github.dockerjava.core.exec.InspectContainerCmdExec@53f76db3
2019-04-10 16:30:12.019 DEBUG   --- [     ducttape-0] c.g.d.core.exec.InspectContainerCmdExec  : GET: OkHttpWebTarget(okHttpClient=org.testcontainers.shaded.okhttp3.OkHttpClient@53d102a2, baseUrl=http://docker.socket/, path=[/containers/f949e1eaf71732d083b7ac8751210643c379ec434f77fde806518aeda2eb8a35/json], queryParams={})

Steps to reproduce

• make project WITHOUT 'com.mysql.jdbc.Driver'
• use MySQLContainer
• run

Symptom

CPU usage is up to 30~40%
o.r.ducttape.unreliables.Unreliables : Retrying lambda call on attempt 1161 is printed inwhile(true)`

---

testcontainers-java/modules/jdbc/src/main/java/org/testcontainers/containers/JdbcDatabaseContainer.java

Lines 125 to 146 in 2da17b9

	protected void waitUntilContainerStarted() {
	// Repeatedly try and open a connection to the DB and execute a test query
	logger().info("Waiting for database connection to become available at {} using query '{}'", getJdbcUrl(), getTestQueryString());
	Unreliables.retryUntilSuccess(getStartupTimeoutSeconds(), TimeUnit.SECONDS, () -> {
	if (!isRunning()) {
	throw new ContainerLaunchException("Container failed to start");
	}
	try (Connection connection = createConnection("")) {
	boolean success = connection.createStatement().execute(JdbcDatabaseContainer.this.getTestQueryString());
	if (success) {
	logger().info("Obtained a connection to container ({})", JdbcDatabaseContainer.this.getJdbcUrl());
	return null;
	} else {
	throw new SQLException("Failed to execute test query");
	}
	}
	});
	}

If createConnection() raises Exception, isRunning() is called in succession by retryUntilSuccess.

[stale]

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.

[jannis-baratheon]

The cause seems to be that Unreliables#retryUntilSuccess only expect an Exception to be thrown by the poll-lambda whereas a missing driver probably throws an Error. This gets propagated to the executor where most probably it's swallowed with a thread dying silently leading to an infinite busy-loop somewhere.

[stale]

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.

[rnorth]

This should be solved by #1434, so I shall close.