Improve log messages when database container test query fails

[vcvitaly]

Throw an exception if container is started but test sql query cannot be executed (cannot connect to database port or smth else).

Fixes #2878

[vcvitaly]

No sure if it was made on purpose. The local variable hides the instance variable and seemed redundant.

[bsideup]

@vcvitaly could you please revert changes unrelated to the MySQL message issue? Feel free to submit them separately, but this PR should have the bare minimum to verify the fix.

[vcvitaly]

@bsideup

@vcvitaly could you please revert changes unrelated to the MySQL message issue? Feel free to submit them separately, but this PR should have the bare minimum to verify the fix.

Done, how do I submit them? Do I open an issue tagged "refactoring" or just submit a PR?

[vcvitaly]

Also, I wasn't sure if I have to write a test and how. Although I'd like to, I haven't found a way to simulate a delay.

[vcvitaly]

The fix also depends on #3018 since the logging is not working in the current implementation for some log levels.

[bsideup]

@vcvitaly

since the logging is not working in the current implementation for some log levels.

could you please clarify what exactly does not work?

Re testing, you can override mysql's command and make it sleep for a second or two before calling mysqld

[vcvitaly]

@bsideup

could you please clarify what exactly does not work?

The exception I throw from GenericContainer#waitUntilContainerStarted is caught an should be logged by this piece of code:

try {
        waitUntilContainerStarted();
} catch (Exception e) {
                logger().debug("Wait strategy threw an exception", e);

But since logger name provided by DockerLoggerFactory is effectively "${dockerImageName}" it won't fall under "org.testcontainers" logger but rather under root where level is "INFO". An exception will be thrown further and container startup will fail but the exact reason won't be printed.

<root level="INFO">
        <appender-ref ref="STDOUT"/>
    </root>

    <logger name="org.testcontainers" level="DEBUG"/>

[vcvitaly]

@bsideup @rnorth @kiview
I have a question here. I was writing a test for my change and I noticed that JdbcDatabaseContainer does all it wait verifications itself instead of using a wait strategy. So I'd like to move all the logic to a separate class JdbcWaitStrategy.

The problem is that I need to get some values from the waitStrategyTarget in order to perform verification. Would it make sense to parametrize the AbstractWaitStrategy?
protected T waitStrategyTarget;

[kiview]

@vcvitaly

I was writing a test for my change and I noticed that JdbcDatabaseContainer does all it wait verifications itself instead of using a wait strategy. So I'd like to move all the logic to a separate class JdbcWaitStrategy.

You are correct with your observation and this implementation is there for legacy reasons. You are also right that this should be tackled in the future, however, this is not necessarily something to take on lightly (this would probably be an API breaking change) and you should not do this as part of this PR.

[vcvitaly]

You are correct with your observation and this implementation is there for legacy reasons. You are also right that this should be tackled in the future, however, this is not necessarily something to take on lightly (this would probably be an API breaking change) and you should not do this as part of this PR.

Ok, is that something I could try doing in a separate PR or shall I leave it for now?

[kiview]

I think it is better to leave this now since I don't think reviewing such a big PR would have a high priority for the core-maintainer team atm and as I said, I see quite some risk in breaking our public API there.

[vcvitaly]

@bsideup I wrote a test for a minimal implementation, please review.

[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.

[bsideup]

@vcvitaly ping

[vcvitaly]

@vcvitaly ping

@bsideup I fixed the typo and left a comment about using Unreliables, I think it won't work. Can the PR be accepted?

[vcvitaly]

@bsideup Ping :)

[rnorth]

Merged. Thank you for your extreme patience, @vcvitaly 🙇‍♂️