-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
GSIP 214
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
©2022 Open Source Geospatial Foundation