On 07/10/2010, at 8:58 AM, Vince Rosso wrote: > > I'm occassionally getting errors of this kind when building: > > org.gradle.api.UncheckedIOException: Could not remove entry > '/var/tmp/build/foo/ubuntu-10.04-64/foo/dependency-cache' from cache > '/ext/home/build/.gradle/caches/0.9-preview-3/outputFileStates/cache.bin'. > Caused by: org.gradle.cache.btree.CorruptedCacheException: Corrupted > IndexBlock 649964 found in cache > '/ext/home/build/.gradle/caches/0.9-preview-3/outputFileStates/cache.bin'. > at > org.gradle.cache.btree.FileBackedBlockStore$BlockImpl.blockCorruptedException(FileBackedBlockStore.java:239) > > > Firstly, yes, we're still using 0.9-preview-3. If there are cache related > changes/fixes in 0.9-rc1, then maybe there's nothing to see here. I'm > reluctant to move to 0.9-rc1 currently as we're approaching a very hard > deadline and I don't want to introduce any issues. The current system works, > albeit with some hiccups. But hiccups I can deal with. Deleting the caches > seems to resolve this issue. > > A little background: we have an automated build system where a "build" user > checks if there have been recent svn checkins into a project. If so, it > checks out the code and builds it to a central repository. This can happen > for many projects at the same time and so multiple gradle processes would > access the gradle caches simultaneously. > > The other issue is that since this automated build process checks out the > code to a new, unique tmp directory every time its going to build, gradle > sees this as a completely new build and creates a new directory in > ~/.gradle/caches/0.9-preview-3/scripts for the compiled build scripts. It > seems to use a hash of the project directory path. These never get cleaned > out so we're actually running into the subdirectory file system limit (e.g. > a directory can't hold more than 32768 subdirectories in EXT2). The easy > workaround is to just clean out that directory via a cron job, but this is > probably a gradle issue. > > I guess the short of it is, has anyone seen these issues before (I don't see > anything in JIRA)? I'm assuming they're a bit unique due to our > infrastructure. Would 0.9-rc-1 help? Since I'm not running the rc1 I haven't > filed these in JIRA yet.
I don't think 0.9-rc1 will help. Could you add some JIRA issues for these problems you've seen? A simple work around is to use a separate user home directory for each build. You can do this using the -g command-line option. One problem with this approach is that Gradle will download all dependencies for every build, as the dependency cache in the user home directory will be empty. This may or may nor be a problem in your case. A fix would be to symlink the 'cache' dir in the user home dir to ~/.gradle/cache -- Adam Murdoch Gradle Developer http://www.gradle.org CTO, Gradle Inc. - Gradle Training, Support, Consulting http://www.gradle.biz
