Skip to content
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

Switch browser containers to use LogMessageWaitStrategy #328

Merged
merged 3 commits into from
May 1, 2017

Conversation

rnorth
Copy link
Member

@rnorth rnorth commented Apr 15, 2017

Reduces default browser container startup timeout to 15s, down from an
unnecessarily high 120s.

This also replaces inheritance-based waitUntilContainerStarted with
composition-based WaitStrategy. The new LogMessageWaitStrategy allows
us to wait based upon the Selenium container log output, rather than the
relatively expensive process of repeatedly trying to create and connect
a RemoteWebDriver instance.

@rnorth rnorth requested a review from bsideup April 15, 2017 19:55
@rnorth
Copy link
Member Author

rnorth commented Apr 15, 2017

FYI @kiview
😍 LogMessageWaitStrategy


// Use multiple startup attempts due to race condition between Selenium being available and VNC being available
VncRecordingSidekickContainer recordingSidekickContainer = new VncRecordingSidekickContainer<>(this)
.withStartupAttempts(3);
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

N.B. this has become necessary because we're now much quicker at starting the WebDriver connection; it exposes a race condition against the VNC socket.

In my testing this led to ~5% of tests randomly failing due to the vnc recorder getting 'Connection Refused'.

Adding multiple startup attempts for the VNC recorder resolves the issue; we could potentially include a wait in the VNC recorder (or here), but that adds a bit more complexity.


@Test
public void simpleTest() throws IOException {
doSimpleWebdriverTest(chromeWithCustomTimeout);
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No assertion in this test unfortunately; I couldn't think of a way to do it that wasn't over-engineered. In manual testing I've dialled this right down to 1 second to verify that the timeout is having an effect.


logger().info("Obtained a connection to container ({})", BrowserWebDriverContainer.this.getSeleniumAddress());
return driver;
});
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can avoid having all this code, which is nice.

@rnorth rnorth force-pushed the fix-326-configurable-startup-timeouts branch from 234215b to 4ec0001 Compare April 17, 2017 05:23
@rnorth rnorth force-pushed the fix-326-configurable-startup-timeouts branch from 4ec0001 to 564583e Compare April 30, 2017 07:16
Reduces default browser container startup timeout to 15s, down from an
unnecessarily high 120s.

This also replaces inheritance-based `waitUntilContainerStarted` with
composition-based `WaitStrategy`. The new `LogMessageWaitStrategy` allows
us to wait based upon the Selenium container log output, rather than the
 relatively expensive process of repeatedly trying to create and connect
 a `RemoteWebDriver` instance.
…iner

This change makes docker-java NO LONGER SHADED into testcontainers core JAR
@rnorth rnorth force-pushed the fix-326-configurable-startup-timeouts branch from 144e7ee to c962b0f Compare April 30, 2017 18:54
@rnorth rnorth merged commit c03fba3 into master May 1, 2017
@rnorth rnorth deleted the fix-326-configurable-startup-timeouts branch May 1, 2017 19:30
@rnorth
Copy link
Member Author

rnorth commented May 27, 2017

Argh, there's a problem with this - I think that at some point before v3.4.0 of selenium the readiness text changed. Might need a regex update....

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant