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

[FIX JENKINS-15331] Retry failed file delete operations #1209

Closed
wants to merge 0 commits into from

Conversation

6 participants
@pjdarton
Copy link
Contributor

commented Apr 22, 2014

This changes Jenkins' strategy when doing recursive deletes so that it no longer stops iterating through a directory when it finds a file it can't delete - it'll try to delete what it can before throwing the exception.
It also changes the default number of attempts that Jenkins makes when doing a recursive delete from 2 attempts to 3 attempts.
This combination results in a dramatic improvement in deletion reliability on Windows-based job executors.

Lastly, this behavior is now configurable (on a per-JVM basis), albeit crudely - like the existing hudson.Util.noSymlink & hudson.Util.symlinkEscapeHatch flags, these can be configured using -D options when starting the Jenkins or slave services.

-Dhudson.Util.deletionRetries=3
Sets the number of times Jenkins will try to delete a file before giving up.
Defaults to 3 attempts.

-Dhudson.Util.deletionRetryWait=100
Sets the time (in milliseconds) for which Jenkins will pause between delete attempts.
Defaults to 100ms between each attempt.
If set to a negative number, it will delay for a linearly increasing amount between attempts.

-Dhudson.Util.performGCOnFailedDelete=false
If set to true, this tells Jenkins to run the Garbage Collector between attempts (just in case the process holding a file open is an un-garbage-collected Java filehandle within Jenkins itself).
It defaults to false.

(Note: This was reworked to patch the Jenkins master branch as of 12:30 GMT April 22 2014, and superceeds pull request 1183)

@cloudbees-pull-request-builder

This comment has been minimized.

Copy link

commented Apr 22, 2014

core » jenkins-core #576 SUCCESS
This pull request looks good

@cloudbees-pull-request-builder

This comment has been minimized.

Copy link

commented May 20, 2014

core » jenkins-core #714 SUCCESS
This pull request looks good

@pjdarton pjdarton changed the title Fix for JENKINS-15331 [FIX JENKINS-15331] Retry failed file delete operations May 23, 2014

@daniel-beck

This comment has been minimized.

Copy link
Member

commented Jul 13, 2014

A workaround for file locking issues on Windows seems like a worthwhile addition. IMO this issue is the reason I'd advice even Windows shops to run their Jenkins master on Linux, which is ridiculous. As this is optional and opt-in it should be safe enough to merge.

@pjdarton Could you update your PR so it can be merged without conflicts?

@olivergondza

This comment has been minimized.

Copy link
Member

commented Jul 13, 2014

Does it make sense to call System.gc() more than once in case the deletion was not successful?

@oleg-nenashev

This comment has been minimized.

Copy link
Member

commented Nov 17, 2014

@olivergondza
It may help if a resource is being handled in parallel threads.

I'm still aware that the code suppresses InterruptedException in waitBetweenDeletes. It would make sense to re-throw it at least. BTW, it is acceptable for custom system properties.

@jhasse

This comment has been minimized.

Copy link
Member

commented Mar 27, 2015

Any news on this?

@olivergondza

This comment has been minimized.

Copy link
Member

commented Mar 27, 2015

This is what my current thinking is: JENKINS-27648.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.