Module (version)
spring-boot-testcontainers (3.1.0)
Host OS
macOS Ventrua 13.0
Host Arch
ARM (Apple M2)
Docker version
Client:
Version: 23.0.1-rd
API version: 1.41 (downgraded from 1.42)
Go version: go1.19.5
Git commit: 393499b
Built: Fri Feb 10 16:54:39 2023
OS/Arch: darwin/arm64
Context: default
Server:
Engine:
Version: 20.10.20
API version: 1.41 (minimum version 1.12)
Go version: go1.18.7
Git commit: 03df974ae9e6c219862907efdd76ec2e77ec930b
Built: Wed Oct 19 02:58:31 2022
OS/Arch: linux/arm64
Experimental: false
containerd:
Version: v1.6.8
GitCommit: 9cd3357b7fd7218e4aec3eae239db1f68a5a6ec6
runc:
Version: 1.1.4
GitCommit: 5fd4c4d144137e991c4acebb2146ab1483a97925
docker-init:
Version: 0.19.0
GitCommit:
What happened?
Using a base test class like so:
@SpringBootTest
@AutoConfigureMockMvc
@Testcontainers
@ActiveProfiles("it")
abstract class BaseITCase {
@Container
@ServiceConnection
static final PostgreSQLContainer<?> postgres = new PostgreSQLContainer<>("postgres:15-alpine");
}
When running tests that extend this class, sometimes they hang with the following error:
2023-07-04T16:43:01.965-03:00 WARN 51304 --- [ main] com.zaxxer.hikari.pool.PoolBase : HikariPool-2 - Failed to validate connection org.postgresql.jdbc.PgConnection@1191029d (This connection has been closed.). Possibly consider using a shorter maxLifetime value.
Comment From: wilkinsona
Thanks for the report but I can't see how you're using reusable containers. The steps described in the Testcontainers docs appear to be missing. To remove any confusion, can you please provide a complete, yet minimal sample that reproduces the problem?
Comment From: eduardolbueno
I think I misunderstood the concept of reusable containers. I meant a container reused throughout a test suite, which I understand is not persistent, in contrast to the "reusable" concept?
Anyway I can't share more code than this, a few classes that extend this base class with jupiter's @Test and assertTrue(true) is enough for the context to hang waiting for a connection.
Comment From: wilkinsona
We don't need your actual code, and would prefer not to have it. All we need is a minimal example.
If you would like us to spend some more time investigating, please spend some time creating a minimal example with "a few classes that extend this base class with jupiter's @Test and assertTrue(true). You can share it with us by pushing it to a separate repository on GitHub or by zipping it up and attaching it to this issue.
Comment From: spring-projects-issues
If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.
Comment From: harissecic
@eduardolbueno Same thing for MongoDB. Simply adding @ServiceConnection won't replace properties and thus connections won't be established by Spring modules. Containers do run but properties are still loaded from the application.yaml so URLs are incorrect. Maybe having application.yaml and application-test.yaml confuse the service connection annotation and it fails or it's just a simple bug of not being able to override properties. I suggest to still manually set connection strings and try it like that.
Comment From: magnus-larsson
I have put together a minimal example that demonstrates how the use of @Container with Spring Boot 3.1.2 breaks testcontainers singleton pattern described here: https://java.testcontainers.org/test_framework_integration/manual_lifecycle_control/#singleton-containers.
Note: Let me know if you think this should be reported in a separate issue.
The example contains two test classes that share a common base class that configure a singleton test container for MySQL. When running tests, it is expected that only one MySQL test container is created.
To reproduce the problem, run the following commands:
git clone https://github.com/magnus-larsson/sb312-tc-singleton-bug.git
cd sb312-tc-singleton-bug
./gradlew test | grep "Creating container for image: mysql:8.0.32"
Expect the following output demonstrating that two MySQL test containers (incorrectly) were created:
2023-07-24T08:55:36.607+02:00 INFO --- [ Test worker] tc.mysql:8.0.32 : Creating container for image: mysql:8.0.32
2023-07-24T08:55:46.547+02:00 INFO 73329 --- [ Test worker] tc.mysql:8.0.32 : Creating container for image: mysql:8.0.32
OpenJDK 64-Bit Server VM warning: Sharing is only supported for boot loader classes because bootstrap classpath has been appended
Edit src/test/java/se/magnus/microservices/core/review/MySqlTestBase.java and comment out the @Container annotation.
Rerunning the tests demonstrates that only one MySQL test container was created:
./gradlew test | grep "Creating container for image: mysql:8.0.32"
Expected output:
2023-07-24T08:57:37.476+02:00 INFO --- [ Test worker] tc.mysql:8.0.32 : Creating container for image: mysql:8.0.32
OpenJDK 64-Bit Server VM warning: Sharing is only supported for boot loader classes because bootstrap classpath has been appended
Comment From: wilkinsona
Thanks, @magnus-larsson. You don't appear to be using @ServiceConnection (I saw it in one test but it was commented out) so it looks like you have a different, but possibly related, problem. As such, if @ServiceConnection isn't involved, please do open a separate issue because any fix that is necessary is likely to be applicable to 2.7.x and later whereas @ServiceConnection is only 3.1.x and later.
Comment From: magnus-larsson
It is using @ServiceConnection, my intention is to replace @DynamicPropertySource annotated method.
But then I discovered this bug and noted that it actually is adding the @Container annotation that triggers the bug, not the @ServiceConnection annotation.
No problem, I will create a new issue.
Comment From: magnus-larsson
Here it is: #36513
Comment From: wilkinsona
@mhalbritter's analysis of #36513 has shown that they are in fact the same problem. @eduardolbueno is also using @Testcontainers which cannot be used with singleton containers.