-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
Do not run "docker ps -a" in ResourceReaper to avoid TooLongFrameException from Netty #295
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 withTooLongFrameException
from Netty ( see docker-java/docker-java#603 ) if host has a lot of different containers, including stopped ones.We inspect later, so
listContainersCmd
is not needed and must be removed to avoid the performance penalty.