There's often a need to programmatically drop all caches related to a store, a feature type or a coverage, but GeoServer lacks a direct API to perform such a cleanup:

• The /reset endpoint clears every cache, causing potentially costly re-creation of the caches (dropping and re-creating pools, computing feature types, and so on)
• For stores, one can use a PUT request that just sets back the original values, or an almost empty one, that won't actually change any property. This is however hard to discover.
• For feature types, the above does not really work, as the ContentDataStore family keeps an internal cache of the feature types, so for example, it won't notice that a table structure changed unless the store is completely dropped.

Andrea Aime

This proposal is for GeoServer 2.22-RC

• Under Discussion
• In Progress
• Completed
• Rejected
• Deferred

Provide an explicit, clear, reliable cache reset API for stores, coverages and feature types (other cache resets are out of scope, but could be added by willing contributors).

REST API wise, the following new resources would be added, mimicking the existing reset one, but with a narrower cleanup focus:

• [POST] /workspaces/<ws>/datastores/<cs>/reset

• [POST] /workspaces/<ws>/coveragestores/<cs>/reset

• [POST] /workspaces/<ws>/datastores/<ds>/featuretypes/<ft>/reset

• [POST] /workspaces/<ws>/coveragestores/<cs>/coverages/<c>/reset

Implementation wise, the controllers would call onto the ResourcePool methods. As a small oddity, for coverages there is no per coverage cache, but only a coverage reader one. We'll add a method clearing the cache for a CoverageInfo for uniformity, as it would be harder to explain why the coverages do not have a reset, and the caching implementation could change in the future to perform coverage specific caching.

As suggested in the introduction, the above won't be sufficient for the ContentDataStore family, and more in general, for any store that's keeping cached state. Turns out the ResourcePool already has special handling of that case via the flushDataStore method, which targets specifically ContentDataStore.

This might be enough, if we want to generalized, the following interfaces could be created at the GeoTools level:

/**
 * A DataAccess holding some cache for the feature types it serves. 
  */
public interface CachingDataAccess {

  /**
   * Clears the cache for the given type name
   */
  public void clear(Name name);
}

/**
 * A DataAccess holding some cache for the feature types it serves. 
  */
public interface CachingDataStore extends CachingDataAccess {

  /**
   * Clears the cache for the given type name
   */
  public void clear(String name);
}

ContentDataStore would then implement the latter, calling internally onto removeEntry(Name), and the ResourcePool ad-hoc handling of ContentDataStore could be simplified.

Additional capabilities, there should not be any backwards compatibility concerns. As a result, we'd like to backport the changes after a bit of cooldown period.

Project Steering Committee:

• Alessio Fabiani: +1
• Andrea Aime: +1
• Ian Turton: +1
• Jody Garnett: +1
• Jukka Rahkonen:
• Kevin Smith:
• Simone Giannecchini: +0
• Torben Barsballe: +1
• Nuno Oliveira: +1

• GEOS-10610
• GEOS-6637