[Feature]: Container startup attempt backoff strategy

Module

None

Problem

I have a JUnit test extension that starts up a container. If multiple tests are executing in parallel in isolated JVMs, they contend for the container name and port bindings. One can work around this by giving it effectively infinite startup attempts and a reasonable startup timeout, but this generates excessive test logs from constant startup attempts.

Solution

Introduce a startup attempt backoff strategy option when constructing a container. Being able to exponentially backoff to a reasonable interval between startup attempts would help in reducing logs.

Benefit

This would benefit any situation where there is contention for exclusive resources between container instances, or any other situation where container startups are very flaky for an extended period, but eventual success is likely.

Alternatives

At the moment I'm using Awaitility to check for container name contention before attempting startup.

Would you like to help contributing this feature?

Yes

The issue does not identify files, tests, or an entry point, so first trace the container startup attempt and retry handling used when constructing a container. Define the configurable backoff behavior, including exponential delays and its interaction with startup attempts and timeouts; done means contention can be retried with fewer logs while eventual startup remains possible.