-
Notifications
You must be signed in to change notification settings - Fork 1
GSIP 136
Create an ResourceNotificationDispatcher API, to inject into the ResourceStore implementation allowing dispatch of event notification to be handled differently for a clustered environment.
Jody Garnett, Niels Charlier
This proposal is for GeoServer 2.9.
- Under Discussion
- In Progress
- Completed
- Rejected
- Deferred
Niels has been working hard on JDBCResourceStore, pull request #1361, which introduces the concept of a ResourceNotificationDispatcher - factoring out event handling from resource storage.
We have two implementations of ResourceStore:
- FileSystemResourceStore - stores resources as files, using a FileSystemWatcher to notice changes to files or directories
- JDBCResourceStore - stores resources as blobs, noticing changes as they are applied via ResourceStore
Right now notification is built into each implementation. The proposal is to create an API ResourceNotificationDispatcher to inject into the ResourceStore for management of event notification.
This approach provides:
- A centralized location to register for all resource change events (ResourceStore.addListener / removeListener).
- The implementation of notification is independent of the ResourceStore being used (storage is now orthogonal to event notification).
public interface ResourceNotificationDispatcher {
void addListener(String path, ResourceListener listener);
void removeListener(String path, ResourceListener listener);
void changed(ResourceNotification notification);
}
The ResourceNotificationDispatcher can be injected into the ResourceStore during construction. We will need a method to access the resulting implementation:
public interface ResourceStore {
...
ResourceNotificationDispatcher getResourceNotificationDispatcher();
...
}
To complete the API we need to adjust the Resource javadocs to be clear ResourceNotificationDispatcher is being used:
public interface Resource {
...
/**
* ..
* Registers listener with ResourceNotificationDispatcher.
*
* @See ResourceNotificationDispatcher.addListener
*/
void addListener( ResourceListener listener);
/**
* ..
* Removes listener from ResourceNotificationDispatcher.
*
* @See ResourceNotificationDispatcher.addListener.addListener
*/
void removeListener( ResourceListener listener);
...
}
Design notes:
- ResourceNotificationDispatcher can take advantage of paths when notifying listeners based on a single Notification, changes to individual files can trigger Directory listener for example
- This proposal uses String paths when managing listeners, Resources are intended to be "Flyweight" objects and delegate to the ResoruceStore add/remove listener methods to take advantage of the single dispatch provided by ResourceNotificationDispatcher.
Initial vote stalled (too many +0 votes to pass) largely due to lack of time to review.
Further discussion clarified the above proposal but did not change the approach.
Providing access to ResourceNotificationDispatcher replaced use of additional add/remove Listener methods.
Email list discussion clarified that listener notification is not recursive (the Java 7 FileSystemWatcher API will only listen to a directory change, rather than recursively listen to sub folders). This information prevents registering single ResourceListener on the data directory root from being a viable alternative.
Discussion also highlights that use of Java FileSystemWatcher as a desirable undertaking (that is out of scope of this proposal).
This change only adds methods, and clarifies javadoc behaviour, and will not break compatibility.
Project Steering Committee:
- Alessio Fabiani: 0
- Andrea Aime: +1
- Ben Caradoc-Davies: +1
- Brad Hards: +1
- Christian Mueller: 0
- Ian Turton: 0
- Jody Garnett: +1
- Jukka Rahkonen: 0
- Kevin Smith: +1
- Simone Giannecchini:
Committers:
©2020 Open Source Geospatial Foundation