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

Pulling of images and Selenium startup failures more likely to cause container startup timeout in v1.1.0 #172

Closed
rnorth opened this issue Jul 14, 2016 · 3 comments
Milestone

Comments

@rnorth
Copy link
Member

rnorth commented Jul 14, 2016

See #170 (comment). Thanks to @ihabsoliman for finding this.

rnorth added a commit that referenced this issue Jul 16, 2016
…mage pull is involved.

Set startup checks for docker-compose to wait indefinitely (until compose terminates).
Improve logging on container startup failure by ensuring that all logs have been fetched before the test terminates.

Helps with #172
rnorth added a commit that referenced this issue Jul 16, 2016
…mage pull is involved.

Set startup checks for docker-compose to wait indefinitely (until compose terminates).
Improve logging on container startup failure by ensuring that all logs have been fetched before the test terminates.

Helps with #172
@rnorth rnorth modified the milestone: 1.1.1 Jul 16, 2016
@rnorth rnorth changed the title Pulling of images more likely to cause container startup timeout in v1.1.0 Pulling of images and Selenium startup failures more likely to cause container startup timeout in v1.1.0 Jul 17, 2016
@rnorth
Copy link
Member Author

rnorth commented Jul 17, 2016

I'm also going to reinstate startup retries to aid with this; another source of random failures is Selenium browser containers failing to start correctly. I've seen this numerous times and there doesn't appear to be any pattern to it; retrying startup of the selenium containers specifically seems to be the least risky option.

As such, I'm reinstating the container startup retry that I removed for v1.1.0, but am making it optional (defaulting to only one attempt). This allows flexibility without forcing all container usage into using startup retries.

@rnorth
Copy link
Member Author

rnorth commented Jul 17, 2016

V1.1.1 released just now includes fixes for this issue

@rnorth rnorth closed this as completed Jul 17, 2016
@ihabsoliman
Copy link

ihabsoliman commented Jul 18, 2016

So I was just testing the new version and I got this
I ran this mvn clean install

java.lang.NoSuchMethodError: org.testcontainers.containers.PostgreSQLContainer.withStartupAttempts(I)V
    at com.jive.jci.commons.itest.AbstractJdbcIntegrationTestLauncher.initDb(AbstractJdbcIntegrationTestLauncher.java:90)
    at com.jive.jci.commons.itest.AbstractJdbcIntegrationTestLauncher.init(AbstractJdbcIntegrationTestLauncher.java:65)
    at com.jive.jci.ambassador.itest.AbstractJdbcAmbassadorTestLauncher.init(AbstractJdbcAmbassadorTestLauncher.java:65)
    at com.jive.jci.ambassador.itest.providers.ProvidersIntegrationTestLauncher.init(ProvidersIntegrationTestLauncher.java:34)
    at com.jive.jci.ambassador.itest.providers.AbstractProvidersIT.setupClass(AbstractProvidersIT.java:94)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:498)
    at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
    at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
    at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
    at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
    at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
    at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
    at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
    at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
    at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
    at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
    at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
    at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
    at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)

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

No branches or pull requests

2 participants