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

Upgrade testcontainers to 1.7.2 #12821

Closed
mbhave opened this issue Apr 10, 2018 · 7 comments
Closed

Upgrade testcontainers to 1.7.2 #12821

mbhave opened this issue Apr 10, 2018 · 7 comments
Labels
type: task A general task
Milestone

Comments

@mbhave
Copy link
Contributor

mbhave commented Apr 10, 2018

Some of the tests that use testcontainers have been quite flaky on CI. We should see if upgrading fixes that.

@mbhave mbhave added the type: task A general task label Apr 10, 2018
@mbhave mbhave added this to the 2.0.x milestone Apr 10, 2018
@bsideup
Copy link
Contributor

bsideup commented Apr 11, 2018

@mbhave please keep me updated about the flakiness :)
The core itself is stable, should be, but maybe there are some images which need bigger startup timeouts or something.
Do you have a link to some CI failures related to the TC usage?

@philwebb
Copy link
Member

@bsideup Here's a recent example. I have a feeling it's related to our CI setup but upgrading to the latest testcontainers can't hurt.

@mbhave mbhave modified the milestones: 2.0.x, 2.0.2 Apr 11, 2018
@mbhave mbhave closed this as completed in 4fab679 Apr 11, 2018
@bsideup
Copy link
Contributor

bsideup commented Apr 12, 2018

@philwebb I checked the error, most of the time it happens when DB inside a container fails to start. In your case it might be that Cassandra didn't start because of OOM or similar reason. If you check the logs, there should be stdout & stderr of the container that failed to start (we do it automatically on start failure), they should help to check if it is container's problem or not, I hope that helps :)

@mbhave
Copy link
Contributor Author

mbhave commented Apr 12, 2018

Thanks for looking into it @bsideup! We'll investigate further.

@wilkinsona
Copy link
Member

wilkinsona commented Apr 25, 2018

Hi, @bsideup. We've just seen a build fail due to an IO timeout when retrieving an image:

org.testcontainers.containers.ContainerFetchException: Can't get Docker image: RemoteDockerImage(imageName=redis:4.0.6)
	at org.testcontainers.containers.GenericContainer.getDockerImageName(GenericContainer.java:841)
	at org.testcontainers.containers.GenericContainer.setDockerImageName(GenericContainer.java:829)
	at org.testcontainers.containers.GenericContainer.<init>(GenericContainer.java:185)
	at org.springframework.boot.testsupport.testcontainers.Container.lambda$new$0(Container.java:53)
	at org.springframework.boot.testsupport.testcontainers.Container.apply(Container.java:70)
	at org.springframework.boot.testsupport.testcontainers.RedisContainer.apply(RedisContainer.java:27)
	at org.junit.rules.RunRules.applyAll(RunRules.java:26)
	at org.junit.rules.RunRules.<init>(RunRules.java:15)
	at org.junit.runners.ParentRunner.withClassRules(ParentRunner.java:245)
	at org.junit.runners.ParentRunner.classBlock(ParentRunner.java:194)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:362)
	at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
	at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:273)
	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
	at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:379)
	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:340)
	at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:125)
	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:413)
Caused by: com.github.dockerjava.api.exception.InternalServerErrorException: {"message":"Get https://registry-1.docker.io/v2/: dial tcp: lookup registry-1.docker.io on 10.192.2.10:53: read udp 10.254.0.230:58499->10.192.2.10:53: i/o timeout"}
	at com.github.dockerjava.netty.handler.HttpResponseHandler.channelRead0(HttpResponseHandler.java:109)
	at com.github.dockerjava.netty.handler.HttpResponseHandler.channelRead0(HttpResponseHandler.java:33)
	at org.testcontainers.shaded.io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
	at org.testcontainers.shaded.io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
	at org.testcontainers.shaded.io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
	at org.testcontainers.shaded.io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
	at org.testcontainers.shaded.io.netty.handler.logging.LoggingHandler.channelRead(LoggingHandler.java:241)
	at org.testcontainers.shaded.io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
	at org.testcontainers.shaded.io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
	at org.testcontainers.shaded.io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
	at org.testcontainers.shaded.io.netty.channel.CombinedChannelDuplexHandler$DelegatingChannelHandlerContext.fireChannelRead(CombinedChannelDuplexHandler.java:438)
	at org.testcontainers.shaded.io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:310)
	at org.testcontainers.shaded.io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:284)
	at org.testcontainers.shaded.io.netty.channel.CombinedChannelDuplexHandler.channelRead(CombinedChannelDuplexHandler.java:253)
	at org.testcontainers.shaded.io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
	at org.testcontainers.shaded.io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
	at org.testcontainers.shaded.io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
	at org.testcontainers.shaded.io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1334)
	at org.testcontainers.shaded.io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
	at org.testcontainers.shaded.io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
	at org.testcontainers.shaded.io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:926)
	at org.testcontainers.shaded.io.netty.channel.epoll.AbstractEpollStreamChannel$EpollStreamUnsafe.epollInReady(AbstractEpollStreamChannel.java:997)
	at org.testcontainers.shaded.io.netty.channel.epoll.EpollDomainSocketChannel$EpollDomainUnsafe.epollInReady(EpollDomainSocketChannel.java:138)
	at org.testcontainers.shaded.io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:401)
	at org.testcontainers.shaded.io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:306)
	at org.testcontainers.shaded.io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:858)
	at org.testcontainers.shaded.io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:138)
	at java.lang.Thread.run(Thread.java:748)

There seems to be some retry logic in RemoteDockerImage but, assuming I've read the code correctly, it will only apply to a DockerClientException which InternalServerErrorException is not. Is there anything we can do to cause such failures to be retried, or perhaps it would be appropriate for Testcontainers to retry by default?

@bsideup
Copy link
Contributor

bsideup commented Apr 26, 2018

Hi @wilkinsona,

it seems that the behaviour was changed in docker-java, AFAIR it was throwing DockerClientException, so indeed we should fix it in Testcontainers, thanks for letting us know 👍

Could you please report it at https://github.com/testcontainers/testcontainers-java/issues?
I'm fixing it already but would be nice to have a paper trail :)

@wilkinsona
Copy link
Member

Done. Thanks for the support, @bsideup!

@wilkinsona wilkinsona changed the title Upgrade testcontainers to 1.7.0 Upgrade testcontainers to 1.7.2 May 1, 2018
wilkinsona added a commit that referenced this issue May 1, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: task A general task
Projects
None yet
Development

No branches or pull requests

4 participants