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

Actor invocations should clean up after themselves #12

Closed
deardooley opened this issue Nov 8, 2015 · 5 comments
Closed

Actor invocations should clean up after themselves #12

deardooley opened this issue Nov 8, 2015 · 5 comments

Comments

@deardooley
Copy link

Currently when invoking actors repeatedly, the completed containers are left on the execution host. This creates a heck of a stockpile of containers and disk. Having them cleaned up after completion would help the system stay up longer, achieve better throughput, and handle requests for larger containers more promptly.

@joestubbs
Copy link

Yes, this is actually fixed in the current version but not deployed to staging yet.

@deardooley
Copy link
Author

How is it configured? I’m running from the repo.


Rion

On Nov 8, 2015, at 7:30 AM, Joe Stubbs notifications@github.com wrote:

Yes, this is actually fixed in the current version but not deployed to staging yet.


Reply to this email directly or view it on GitHub #12 (comment).

@joestubbs
Copy link

Hmm, there's no configuration needed. You are seeing actor containers pile up? If so, that's a bug. The commit was from October: 61407c8

@joestubbs
Copy link

Pushed a fix. Docker 1.9 broke the stats API since there are multiple networks now, a network must be selected. Since stats collection happens before removal, it was breaking container removal as well. Two of the automated tests are still failing, so I am continuing to look, but manual testing appears to be working.

@joestubbs
Copy link

Test are now passing and staging has been updated. Closing out.

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