Clone Tools
  • last updated a few seconds ago
Constraints: committers
Constraints: files
Constraints: dates
Move org.gradle.cache.internal to persistent-cache project

+review REVIEW-6562

  1. … 184 more files in changeset.
Move some of persistent-cache out of core

+review REVIEW-6562

  1. … 127 more files in changeset.
Add unit test coverage for PersistentCache cleanup actions

+review REVIEW-6510

  1. … 6 more files in changeset.
Automatically clean up the local build cache

- Push cleanup action into PersistentCache

- Automatically run the clean-up action after 30 days

+review REVIEW-6510

  1. … 23 more files in changeset.
Remove `longRunningOperation` from `CacheAccess`

Following the work to perform finer grained locking of the artifact cache, the long running operations are

not required anymore. This commit removes the `longRunningOperation` methods from `CacheAccess` and derivative classes,

but doesn't yet remove the logic in `DefaultCacheAccess` that handled the long running operations so that they

work properly in cross-process mode.

  1. … 8 more files in changeset.
Added `CacheAccess.withFileLock()` to allow an action to run while the current process is holding the lock for a cache, as an alternative and eventual replacement for `useCache()` which also blocks all other threads for the current process and other processes.

  1. … 11 more files in changeset.
Removed the 'description' parameter from the methods of `CacheAccess`. This description is not actually used anywhere and these methods are called many, many times, meaning a lot of unnecessary strings were being created.

  1. … 40 more files in changeset.
Fix cache corruption resulting from cache reuse problem (#1011)

This commit fix issue gradle/gradle#933 by using a deep knowledge of the inner working of Gradle. It assumes the parameters for the cache won't change between the embedded run of Gradle through GradleBuild type task or other.

  1. … 1 more file in changeset.
Fixed issue where an exception was thrown when the cache worker thread releases cache ownership prior to the cache's `get()` method returning a value to the consumer.

  1. … 1 more file in changeset.
Fixed failure when cache file lock is acquired through `CrossProcessCacheAccess`, and made cache initialization more robust in the presence of failures.

  1. … 12 more files in changeset.
Moved responsibility for file locking out of `DefaultCacheAccess`, so that now `CrossProcessCacheAccess` and `CacheAccess` services use the same file lock.

  1. … 8 more files in changeset.
Some initial changes to wire together `CrossProcessCacheAccess` and `CacheAccess` implementations so that they use the same file lock.

  1. … 8 more files in changeset.
Read and update persistent caches in a single worker thread

- other threads communicate with the worker thread via a queue

- all operations happen in the same order as they entered the queue

- writes are asynchronous

- reads block on the requesting side

- worker thread holds the write lock for a limited time (configurable)

to allow other processes to access the same persistent cache

+review REVIEW-6258

  1. … 28 more files in changeset.
Renamed package o.g.messaging.serialize to o.g.internal.serialize.

  1. … 171 more files in changeset.
Moved some caching classes around

  1. … 17 more files in changeset.
Use string name instead of file path when creating an indexed cache.

  1. … 15 more files in changeset.
Changed DefaultCacheAccess to trigger cache initialization whenever the cache is opened on demand, and removed DelegateOnDemandPersistentDirectoryCache.

  1. … 9 more files in changeset.
Moved handling of cache initialisation from DefaultPersistentDirectoryCache/DefaultPersistentDirectoryStore into DefaultCacheAccess, so that it can take care of coordinating things to happen at the right time when the cache is opened. Will allow initialisation to happen when the cache is opened on demand (but doesn't yet).

  1. … 6 more files in changeset.
Plugged some holes in DefaultCacheAccess that allow a thread to use the cache when it does not hold a lock.

Temporarily, still allow a thread to close a shared cache when some other thread is still 'using' the cache.

  1. … 1 more file in changeset.
Fixed DefaultCacheAccess to release cache ownership only if the current thread owns the cache, not if some other thread happens to own the cache.

  1. … 5 more files in changeset.
Reworked how the in-memory task history cache detects changes by other processes.

- Replaced FileLock.getHasBeenUpdated() with getState() that returns a snapshot of the current state that can later be used to check for changes

- Pass this around instead of a boolean to the UnitOfWorkParticipants.

- Replaced DefaultLockState with format specific implementations.

- Changed the lock file format to use a sequence number to detect changes by another process

  1. … 16 more files in changeset.
Fixed issue with propagation of the file lock options in the default cache access. Fixed problem with the cache reset marking the cache as clean initially.

  1. … 2 more files in changeset.
Further work on wrapping LockMode with LockOptions.

  1. … 14 more files in changeset.
Introduced a LockOptions type that wraps LockMode.

  1. … 10 more files in changeset.
Work continues on extracting PersistentIndexedCacheParameters.

  1. … 3 more files in changeset.
REVIEW-2455 Removed unnecessary method from MultiProcessSafePersistentIndexedCache.

1. I needed to relax the validation of getLock() method. Currently, it is possible that the close operation is invoked on a cache that does not have any owner thread (see the unit test). I'm not sure if this approach is good - please review.

2. Reworked the DefaultCacheAccess cache a little bit to make above change possible (cannot clear the lock owner thread before closing the lock).

  1. … 3 more files in changeset.
REVIEW-2455 Attempted to unify the implementation of FileLockContentionHandlers.

1. The attempt has failed. Down the road we want to have a single FileLockManager per process. Getting to that point is not trivial however. The default file lock manager opens a datagram port before creating a lock and requires the clients of the locks to provide reasonable callbacks when lock contention happens. At the moment, we use the default file lock manager in few places where the lock contention handling is absent and adding it is tricky (I'm open to suggestions). Hence perhaps we allow the no-op implementation of lock contention handler in those places for the time being until we have a better reason to push harder for a single file lock manager per process.

2. Rename job and refactoring. Added dedicated method for enabling file lock contention handling on the file lock manager.

  1. … 22 more files in changeset.
REVIEW-2472 Removed dead field from the class. I've tried to rework the test to make it more maintainable (it had lots of mocky interactions and was feeling like an integ test). It's now about 30% smaller yet I think it still has sufficient unit coverage.

    • -271
    • +142
  1. … 1 more file in changeset.
REVIEW-2473 Fixed the problem with DefaultAccessCache - each thread should have its own stack of operations. Extracted some code out and added unit test coverage. Started enabling the DefaultCacheAccessTests.

  1. … 6 more files in changeset.
Fixed the problem with DefaultCacheAccess not allowing to re-enter the longRunningOperation from a different thread.

  1. … 1 more file in changeset.