Conversation
|
Ah, this is an interesting problem. I'm happy to merge - it looks like this check is fairly redundant anyway, and the more specific inspect command later catches the |
## [1.2.0] - 2017-03-12 ### Fixed - Fix various escaping issues that may arise when paths contain spaces (#263, #279) - General documentation fixes/improvements (#300, #303, #304) - Improve reliability of `ResourceReaper` when there are a large number of containers returned by `docker ps -a` (#295) ### Changed - Support Docker for Windows via TCP socket connection (#291, #297, #309). _Note that Docker Compose is not yet supported under Docker for Windows (see #306) - Expose `docker-java`'s `CreateContainerCmd` API for low-level container tweaking (#301) - Shade `org.newsclub` and Guava dependencies (#299, #292) - Add `org.testcontainers` label to all containers created by Testcontainers (#294)
|
I've just encountered the following error on the Gitlab CI server of a customer: Does this stem from the same problem? Using testcontainers 1.2.1 here. |
|
Hi @kiview Is it likely that there are a large number of images on the CI machine? As for resolving it, we deliberately fetch all available images and cache it so that we don't have to repeatedly check that the image is available every time we start a container. I will see what practical performance gain this has nowadays, though. Richard |
|
@rnorth You're right, there might be a lot of images on the CI server. I'll check later to give you a concrete number and I'll create an dedicated issue once I know more. |
|
I ran a quick test to check, and I think the impact of adding a smarter filter to the image list query will have a negligible impact on performance. We should be able to improve this! |
|
Or just increase the limit on the Netty handler?
…On Fri, 14 Apr 2017 at 13:40 Richard North ***@***.***> wrote:
I ran a quick test to check, and I think the impact of adding a smarter
filter to the image list query will have a negligible impact on
performance. We should be able to improve this!
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#295 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AA8Y8eXIDUUTHqw_rLN5gyoiATVAQzqhks5rv00MgaJpZM4MGIBM>
.
|
|
I'm afraid that would have to be changed upstream in |
|
@rnorth My client has fixed this problem by deleting the unused images, so yes, it was a problem with the list of available images. Sadly I couldn't get image count before they deleted them, so I don't know a hard number for when the error ocured. |
dockerClient.listContainersCmd().withShowAll(true).exec()fails withTooLongFrameExceptionfrom Netty ( see docker-java/docker-java#603 ) if host has a lot of different containers, including stopped ones.We inspect later, so
listContainersCmdis not needed and must be removed to avoid the performance penalty.