-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use LogMessageWaitStrategy in VncRecordingContainer #2547
Use LogMessageWaitStrategy in VncRecordingContainer #2547
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, the failing build is a completely unrelated problem with DB2 tests on AZP for now.
🤯 this container predates the existence of We should do that...! I'd be OK with keeping this PR as-is, so that it can at least be released soon. |
All right, then I will change it to LogMessageWaitStrategy |
3480d41
to
e911925
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So this will result in 60 seconds default timeout by the way. But thanks for switching out the strategy.
core/src/test/java/org/testcontainers/containers/VncRecordingContainerTest.java
Outdated
Show resolved
Hide resolved
core/src/test/java/org/testcontainers/containers/VncRecordingContainerTest.java
Outdated
Show resolved
Hide resolved
6c7e62f
to
2fd3809
Compare
Merging from master into the PR branch to incorporate #2557 and hopefully fix build. |
This was released in https://github.com/testcontainers/testcontainers-java/releases/tag/1.14.0 🎉 Thanks for the contribution! |
…s#2063) (testcontainers#2547) Co-authored-by: Stefan Rempfer <srempfer@rt.ipnt.de> Co-authored-by: Richard North <rich.north@gmail.com> Co-authored-by: Sergei Egorov <bsideup@gmail.com>
I run in the same issue as described here #2063
After some investigation I found out that the await timeout is to low in slow environments.
This happens also in my development environment - using Docker for Windows 2.2.0.5.
Unfortunately it tooks more than 1 second to retrieve the logs from the container and so the FrameConsumerResultCallback has no chance to count down the latch before the await timeout appears.
For my environment a await timeout of 2 seconds worked but I thought some more time couldn't hurt because it's only the worst case wait time and normally the logs should be retrieved faster.